The problem
You are designing a simple version of Twitter's timeline feature, where users can post tweets and view a feed of recent tweets from people they follow. The system will initially serve a small country, but must be robust enough to handle growth. If the design is wrong, users may experience delays in seeing new tweets or may not see tweets from people they follow. The system must support basic posting and reading, maintain user relationships, and deliver feeds in near real-time.
You are a backend engineer tasked with designing the core timeline system for a new social media platform inspired by Twitter.
If the system is not designed well, users will see old or incomplete timelines, or the system may become unresponsive during peak hours.
Must hold true
- Support at least 1 million users.
- Each user can follow up to 1,000 others.
- Tweets must appear in followers' timelines within 5 seconds.
- System should store at least 1 year of tweets.
Functional Requirements
What the system must DO.
| Requirement | Priority |
|---|---|
| Users must be able to post new tweets. | Must have |
| Users must be able to view a timeline of recent tweets from people they follow. | Must have |
| Users must be able to follow and unfollow other users. | Must have |
Non-Functional Requirements
How well it must do it — latency, availability, scale. Measurable, not vibes.
| Requirement | Priority |
|---|---|
| Tweets should appear in followers' timelines within 5 seconds of posting. | Must have |
| The system must support at least 1 million users. | Must have |
| Store at least 1 year of tweets. | Nice to have |
What you learn by asking
In an interview these facts are NOT volunteered — the candidate earns them with clarifying questions. These are the answers behind this design.
| If you ask about… | The answer |
|---|---|
| User base size | There are 1 million registered users. |
| Tweet volume | On average, each user posts 2 tweets per day. |
| Follow relationships | Each user follows an average of 200 others, with a maximum of 1,000. |
| Timeline reads | Each user checks their timeline 10 times per day on average. |
| Tweet size | Each tweet is about 280 bytes (including metadata). |
| Retention policy | Tweets must be stored for at least 1 year. |
Capacity Estimation
Rough arithmetic turns the requirements into engineering decisions — it tells you which parts need scaling machinery and which are trivially easy. Only the order of magnitude matters.
| Quantity | Answer | How it is derived |
|---|---|---|
| Total tweets per day | ~2M tweets/day | 1 million users × 2 tweets per user per day = 2 million tweets per day. |
| Storage needed for 1 year of tweets | ~204.4B bytes | 2 million tweets/day × 365 days × 280 bytes = 204,400,000,000 bytes (about 204 GB). |
The architecture, one version at a time
Nobody designs the final diagram in one stroke, so this design is built up one component at a time rather than shown finished. Start with the simplest thing that can serve a request, then add each piece and see where it attaches.
Before each new component is named you get a chance to call it yourself. You can stop after any version and still hold a complete, working system in your head — that is the point.
v1 — the simplest thing that works
Start with the smallest design that can actually serve a request: Client App → API Server → Tweet Database. Everything after this exists because something about this version does not hold up.
v1 — the simplest thing that works — the picture
Quick check
Which component do you think this design needs next?
v2 — adding User Database
Why it is here: User and follow data is needed for timelines.
The finished design
The full reference design, with the reason behind every connection. When you practice, you will rebuild this from a palette that includes decoys.
Why each connection exists
- Client AppAPI ServerClient interacts with backend via API.
- API ServerTweet DatabaseTweets are stored and retrieved from database.
- API ServerUser DatabaseUser and follow data is needed for timelines.
The design in one glance
Every component in the design, in the order it becomes necessary. If you can retell this table from memory, you can rebuild the whole architecture on a whiteboard.
| Version | What it adds | Why |
|---|---|---|
| v1 — the simplest thing that works | — the starting point | Start with the smallest design that can actually serve a request: Client App → API Server → Tweet Database. Everything after this exists because something about this version does not hold up. |
| v2 — adding User Database | User Database | User and follow data is needed for timelines. |
API Design
Every operation traces back to a requirement — nothing extra, nothing missing.
| Endpoint | Purpose |
|---|---|
| POST /tweets | Allows a user to post a new tweet. |
| GET /timeline | Fetches the timeline for a user, showing recent tweets from accounts they follow. |
| POST /follow | Allows a user to follow another user. |
| POST /unfollow | Allows a user to unfollow another user. |
Data Model
| Entity | Fields |
|---|---|
| User | user_id: string (Unique user identifier.), username: string (Display name.) |
| Tweet | tweet_id: string (Unique tweet identifier.), user_id: string (Author of the tweet.), content: string (Tweet text.), timestamp: datetime (When the tweet was posted.) |
| Follow | follower_id: string (User who follows.), followee_id: string (User being followed.) |
Defending the Design
Interviewers close by stress-testing the design. Strong answers follow one shape: which component → what breaks there → the fix and its cost. Here are this problem's probes and the points a strong answer hits:
What becomes the bottleneck as user numbers and reads grow, and how would you address it in your design? API server must fetch many tweets for each timeline read, leading to high load.. Tweet database becomes a read bottleneck as timelines are generated on the fly.. Introduce a cache to store precomputed timelines or recent tweets for fast reads..
If the tweet database becomes unavailable, what user-facing failures occur and what mitigation strategies could you propose? Users cannot post new tweets or view timelines.. System should degrade gracefully, e.g., show cached timelines if available.. Consider database replication and failover for higher availability..
If you add a timeline cache, what are the trade-offs in terms of consistency and freshness for users? Cache improves read speed but may serve slightly stale data.. Need to balance cache expiration and update strategies to meet the 5-second freshness requirement.. Complexity increases as cache invalidation and consistency must be managed..
Tip — Key takeaway
A simple Twitter-like timeline system can be built with just clients, an API server, and two databases for tweets and user relationships. As read load grows, caching becomes essential to maintain low latency and system responsiveness. Each added component should address a concrete scaling or latency need, not just complexity for its own sake.
Common trap — Common mistakes on this problem
Adding a queue for timeline reads, which must be synchronous for user experience. · Using a search index for timeline retrieval when simple key lookups suffice. · Storing tweets and user relationships in separate, uncoordinated databases without clear linkage, leading to inconsistent timelines.
You've seen the whole design — now build it yourself
The practice run walks the same steps, but YOU do the work: gather the requirements, run the numbers, wire the architecture — with an AI interviewer and per-step feedback.