The 2027 System Design Interview Playbook: Framework, Concepts, and a Full Worked Example

A quick note before we start: This guide is written by me, Arslan Ahmad. I'm the founder of DesignGurus.io and the author of Grokking the System Design Interview. Before that, I spent years as a software engineer and hiring manager at Microsoft and Meta, where I sat on the other side of hundreds of these interviews. Where one of our courses or articles goes deeper on a topic, I link it. You can follow everything in this playbook without buying anything.

If you're preparing for a system design interview in 2027, you're facing a strange situation. There's more free material than ever, and it has never been harder to know what to study.

Most guides give you one of three things: a list of concepts with no idea how to use them, a framework with no worked example, or a single example with no reusable method. Candidates come out of those guides knowing what a load balancer is but freezing when an interviewer says "Design Instagram's feed. You have 45 minutes."

This playbook gives you all three in one place:

1. A framework you can apply to any question, with a minute-by-minute time budget.
2. The core concepts that show up in nearly every interview, explained at the depth interviewers actually probe.
3. A full worked example (a news feed), done the way I'd want a strong senior candidate to do it, with real numbers, a data model, deep dives, and failure handling.

It's long on purpose. Bookmark it, skim the table of contents, and come back to the sections you need.

TL;DR: The 60-Second Version

• The interview tests how you think, not what you've memorized. There's no single correct answer. There are defensible trade-offs.
• Use a framework every time: clarify requirements → estimate scale → define the API → model the data → high-level design → deep dives → bottlenecks and wrap-up.
• Spend the first ~15 minutes on scope, numbers, API, and data. Candidates who skip this end up designing the wrong system very well.
• Know ~15 building blocks cold: load balancers, caches, CDNs, SQL vs NoSQL, replication, sharding, consistent hashing, queues, rate limiting, idempotency, IDs, CAP/PACELC, consistency models, observability, API styles.
• Every decision should come with a "because." "I'll use Cassandra because the workload is write-heavy, access is by key, and we can tolerate eventual consistency."
• Seniority is judged by how you drive the conversation, not by how many boxes you draw.
• 2027 additions: expect AI/LLM system questions, more focus on cost and observability, and designing APIs that AI agents (not just humans) will call.

Table of Contents

1. What Is a System Design Interview?
2. What's Different About System Design Interviews in 2027
3. The Types of System Design Interviews
4. How You're Evaluated (and What Changes by Level)
5. The 7-Step System Design Interview Framework
6. Core Concepts: The System Design Toolkit
7. The Trade-offs Interviewers Love to Probe
8. Full Worked Example: Design a News Feed
9. Bonus: A Template for AI System Design Questions
10. The Most Common System Design Interview Questions
11. 12 Mistakes That Sink Strong Candidates
12. An 8-Week Preparation Plan
13. Best Resources to Prepare
14. FAQ

What Is a System Design Interview?

A system design interview is a 45 to 60 minute conversation where you design a large-scale software system from a vague prompt. "Design a URL shortener." "Design WhatsApp." "Design a rate limiter." "Design a system that lets 10 million people buy concert tickets at the same moment."

You'll usually work on a whiteboard or a shared online diagramming tool. The interviewer plays a mix of product manager, tech lead, and skeptical colleague. They answer your questions, push on weak spots, and steer you toward the parts they want to see in depth.

What it is not:

• Not a trivia quiz. Nobody will ask you to recite the Raft paper. They'll ask you why you need consensus here and what happens if the leader dies.
• Not a test of whether you've built this exact system. Very few candidates have built Twitter. Interviewers know that.
• Not a search for the "right" architecture. Two candidates can draw very different diagrams and both get a strong hire. What matters is whether your choices fit the requirements and whether you can defend them.

What it is: a simulation of a design review. The question behind every question is, "Would I trust this person to lead the design of a real system on my team?"

That's why the system design round carries so much weight in leveling decisions. A coding round tells a company whether you can write correct code. A system design round tells them whether you're a mid-level, senior, or staff engineer. If you want the long version of how this round fits into the loop, I wrote about it in System Design Interview Fundamentals.

What's Different About System Design Interviews in 2027

The core of the interview hasn't changed in a decade: requirements, scale, components, trade-offs. But the questions and the bar around them have shifted. Here's what I'm seeing from candidates and hiring managers going into 2027.

1. AI system design questions are now mainstream. "Design ChatGPT," "Design a RAG-based support bot," and "Design an LLM inference service" have moved from niche ML loops into general backend loops. You don't need to be an ML researcher, but you do need to know how retrieval, vector search, model serving, token streaming, and GPU cost fit into an architecture. I added a template for these below.

2. Your API's clients might be agents, not people. More systems now have AI agents calling them in tight loops. That raises the stakes on things that used to be "nice to have": idempotency keys, strict rate limits per key, machine-readable errors, pagination that doesn't break under retries, and clear contracts.

3. Cost is a first-class requirement. Interviewers increasingly ask, "What does this cost to run?" A design that needs 4,000 GPUs or petabytes of hot Redis isn't automatically wrong, but you should notice and say so.

4. Observability and failure modes get more airtime. "How would you know it's broken?" and "What happens when the cache cluster dies?" are now standard follow-ups, especially at senior levels.

5. Interviewers expect you to drive. With so much prep material available, the baseline has gone up. Reciting a memorized "Design Twitter" answer stands out less than it used to. Adapting your design to the interviewer's twist stands out more.

6. Some companies now allow AI tools in parts of the loop. Policies vary a lot between companies and change often, so ask your recruiter. Even where AI assistance is allowed, the system design round is still mostly about your judgment: what to build, what to skip, and why.

None of this changes the fundamentals. If anything, it rewards them more. You can't reason about LLM serving costs if you can't do back-of-the-envelope math.

The Types of System Design Interviews

"System design" covers a few different interview formats. Find out which one you're getting, because the prep is different.

Most backend and full-stack engineers will see product design and infrastructure design. Meta, for example, has long split its loop into "product architecture" and "system design" flavors. I break down each format in Types of System Design Interviews: Product, Infrastructure, and More.

This playbook focuses on the product and infrastructure formats, because that's where most people need help. The framework applies to all of them.

How You're Evaluated (and What Changes by Level)

Interviewers don't score your diagram. They score signals. Almost every big-tech rubric I've seen boils down to four:

1. Problem navigation. Do you scope the problem before solving it? Do you ask questions that change the design, not questions for the sake of asking?
2. Solution design. Do the components fit together into something that would actually work end to end?
3. Technical depth. When pushed on a component, do you know why it works, not just what it is?
4. Communication. Do you think out loud, check in, and adjust when the interviewer gives you a hint?

The same question is asked to mid-level, senior, and staff candidates. What changes is the bar.

• L4 / mid-level: You can produce a working design with reasonable components. The interviewer may guide you through some steps. You discuss a couple of trade-offs.
• L5 / senior: You drive the whole conversation without prompting. You pick the two or three hardest parts of the problem and go deep. You back decisions with numbers and plan for failure.
• L6 / staff: You reframe the problem. You compare multiple architectures before committing. You talk about cost, migration paths, operational burden, and what you'd deliberately not build in v1.

Here's a practical way to tell where you are: record yourself doing a mock interview, then count how many times the interviewer had to redirect you. Senior candidates rarely need it. I wrote about the specific behaviors that separate candidates in 7 Tips to Stand Out in Your System Design Interview, and I list level-appropriate practice questions in System Design Interview Questions by Level.

The 7-Step System Design Interview Framework

This is the framework I've taught for years in Grokking the System Design Interview. It's not magic. It just makes sure you never skip the steps that interviewers grade, and it keeps you from panicking when the prompt is vague.

If you prefer video, here's my walkthrough of the same 7-step method:

Let's go through each step: what to do, what to say, and what to avoid.

Step 1: Clarify Requirements (≈5 minutes)

Every system design prompt is underspecified on purpose. The interviewer wants to see whether you'll charge ahead or figure out what you're building first.

Split requirements into two lists and write both on the board.

Functional requirements are what the system does. Aim for 3 to 5 core features, and explicitly park the rest.

"For a news feed, I'm thinking the core features are: users can create posts with text and images, follow other users, and see a feed of posts from people they follow. I'll leave out comments, likes, ads, and search for now unless you'd like me to include them. Does that work?"

Non-functional requirements are how well it does it. These drive the architecture far more than the features do. Ask about:

• Scale: How many users? Daily active users? Read-heavy or write-heavy?
• Latency: What's acceptable for the critical path? (For a feed: p99 under ~200 ms.)
• Availability vs consistency: Is it OK if a post takes a few seconds to appear for followers? (Usually yes.) Is it OK if a payment is double-charged? (Never.)
• Durability: Can we ever lose data? (Posts: no. View counts: maybe.)
• Other constraints: Global or single region? Mobile clients with bad networks? Compliance needs?

Avoid: asking 15 questions in a row. Ask the ones whose answers change the design, propose sensible defaults for the rest, and move on.

Step 2: Back-of-the-Envelope Estimation (≈3–5 minutes)

Estimation turns "it should scale" into "we need roughly this much." Its job is to tell you which parts of the system are hard. A design serving 100 QPS and a design serving 1 million QPS look very different.

Estimate four things:

• Traffic: reads and writes per second, average and peak.
• Storage: per day, per year, and total.
• Bandwidth: bytes in and out per second, mostly relevant for media.
• Memory: what you'd need to cache the hot set.

The trick is to round aggressively. A day has 86,400 seconds; call it 100,000 (10⁵). So 1 million requests/day ≈ 10 per second, and 1 billion/day ≈ 10,000 per second. Interviewers want the order of magnitude and your reasoning, not decimals.

Avoid: spending 10 minutes on math the design doesn't use. Every number you compute should lead to a decision ("~35K peak read QPS, so we need a cache in front of the database").

For a step-by-step method with practice problems, read Back-of-the-Envelope Estimation for System Design Interviews.

Step 3: Define the API (≈3–5 minutes)

The API is the contract between your system and the world. Writing it down forces you and the interviewer to agree on exactly what the system does.

Keep it to the 3 to 5 endpoints that match your functional requirements:

POST /v1/posts { text, media_ids[], idempotency_key } -> 201 { post_id } GET /v1/feed?cursor=&limit=20 -> 200 { items[], next_cursor } POST /v1/users/{id}/follow -> 204 

Things worth mentioning briefly, because they show maturity:

• Pagination: cursor-based, not offset-based, for anything that changes in real time.
• Idempotency keys on writes, so a retried request doesn't create a duplicate.
• Auth and rate limiting at the gateway.
• API style: REST is the default for public APIs, gRPC is common between internal services, and GraphQL fits client-driven aggregation.

Step 4: Model the Data (≈3–5 minutes)

List the core entities, their key fields, and, most importantly, the access patterns. Your database choice should follow from how data is read and written, not from what's fashionable.

Questions to answer:

• What are the main entities and relationships?
• What are the top 2–3 queries? (e.g., "get the latest 20 posts for user X's feed")
• Do we need transactions across entities, or mostly single-key reads and writes?
• How will this be partitioned once it no longer fits on one machine?

A good habit: say out loud which database you'd pick and why, in one sentence. "Follows are a simple many-to-many relationship queried by user ID in both directions. A sharded relational store with two tables, one keyed by follower and one by followee, handles that well."

Step 5: High-Level Design (≈8–10 minutes)

Now draw the boxes. Start with the simplest design that satisfies the functional requirements end to end, then evolve it to meet the non-functional ones.

A reliable approach:

1. Draw the client, the entry point (load balancer / API gateway), and the services that handle each API.
2. Add the data stores from Step 4.
3. Walk through one write request and one read request end to end, out loud.
4. Add caches, queues, CDNs, and replicas only where your numbers from Step 2 say you need them.

Avoid: drawing 25 boxes before explaining any of them. Five well-explained boxes beat twenty-five vague ones.

Step 6: Deep Dives (≈10–12 minutes)

This is where most hiring decisions are made. Pick the two or three components that are hardest for this specific problem and go deep. Often the interviewer will steer you; at senior levels, they want to see you pick.

How to find the hard parts:

• Where does the scale from Step 2 concentrate? (A hot key? A huge fan-out?)
• Where do consistency requirements bite? (Payments, inventory, bookings.)
• What's unique to this problem? (Geospatial search for Uber, fan-out for feeds, contention for ticketing.)

For each deep dive, present two or three options, compare them, then commit. That pattern alone separates many senior candidates from mid-level ones.

Step 7: Bottlenecks, Failures, and Wrap-up (≈5 minutes)

Finish by stress-testing your own design:

• Single points of failure: what happens if each box dies?
• Bottlenecks: which component saturates first as traffic grows 10×?
• Hot spots: celebrity users, viral content, popular keys.
• Observability: what would you monitor and alert on?
• What's next: what would you add with more time?

That last image captures the key point: a system is only as fast as its slowest stage. Scaling your app servers from 8,000 to 80,000 RPS does nothing if the database tops out at 2,000.

Want the full step-by-step breakdown with examples for each step? See System Design Interview Guide – 7 Steps to Ace It.

Core Concepts: The System Design Toolkit

You don't need to know everything about distributed systems. You need a toolkit of roughly 15 concepts that you understand well enough to (a) know when to use each one and (b) answer two levels of "why?" about it.

Here's how they fit together in a typical web system:

1. Scalability: Vertical vs Horizontal

Vertical scaling (scale up) means a bigger machine. It's simple and there are no distributed-system headaches, but there's a ceiling and a single point of failure.

Horizontal scaling (scale out) means more machines. There's effectively no ceiling, but now you need load balancing, data partitioning, and a plan for partial failure.

The interview move: keep your application servers stateless (sessions in a shared store like Redis, files in object storage) so you can scale them horizontally behind a load balancer. Then focus your energy on the stateful parts, which are almost always the hard parts.

2. Load Balancing

A load balancer spreads requests across servers and routes around unhealthy ones.

• L4 (transport layer) balances TCP/UDP connections. It's fast and doesn't look at content.
• L7 (application layer) looks at HTTP paths, headers, and cookies, so it can route /api/video differently from /api/chat.
• Algorithms: round robin, least connections, weighted, and consistent hashing (when you want the same user or key to hit the same server, e.g., for local caches).

Mention health checks, and that the load balancer itself must be redundant (active-passive pairs or a managed cloud LB), or it becomes your single point of failure.

3. Caching

Caching is the highest-leverage tool in system design. Reading from memory is roughly 1,000× faster than a disk-backed database query. A good cache can absorb 90%+ of read traffic.

Know where caches live (client, CDN, application-level like Redis, database buffer cache) and the main write policies:

• Cache-aside (lazy loading): the default. App checks cache, falls back to DB on a miss, then populates the cache.
• Write-through: writes go through the cache to the DB, so the cache is never stale for written keys.
• Write-back: writes go only to the cache and are flushed later. Fastest, but you can lose data.

Then be ready for the follow-ups: How do you invalidate? (TTL plus explicit delete on write.) What's the eviction policy? (Usually LRU.) What happens when a hot key expires and 10,000 requests hit the database at once? (A cache stampede; fix it with request coalescing, jittered TTLs, or proactive refresh.)

Redis comes up in almost every interview, so know its data structures, not just "key → value." Sorted sets (leaderboards, feeds), hashes (objects), and streams (event logs) solve a lot of design problems on their own.

4. Content Delivery Networks (CDNs)

A CDN caches static content (images, video, JS, CSS) at edge locations close to users. It cuts latency for global users and offloads huge amounts of bandwidth from your origin.

Use a CDN for anything large and read-heavy: profile pictures, video segments, thumbnails. Mention cache keys and versioned URLs (e.g., avatar_v3.jpg) so updates don't serve stale content. A cross-continent round trip is ~150 ms, while a CDN edge is often a few milliseconds away.

5. Databases: SQL vs NoSQL

This is one of the most-asked trade-offs. Don't answer with "NoSQL scales better." Answer with access patterns.

A strong answer sounds like: "Orders need multi-row transactions and strong consistency, so PostgreSQL. The activity log is append-heavy, read by user ID and time range, and can be eventually consistent, so Cassandra."

Also know the specialized stores: object storage (S3) for blobs, search indexes (Elasticsearch/OpenSearch) for full-text search, time-series databases for metrics, graph databases for deep relationship queries, and vector databases for embeddings in AI systems.

For the deeper comparison, see SQL vs. NoSQL: Key Differences.

6. Indexing

An index makes reads fast at the cost of slower writes and extra storage. B-tree indexes handle range queries; hash indexes handle exact matches. LSM-tree storage engines (Cassandra, RocksDB) make writes cheap by appending and compacting later.

The interview-relevant point: design your indexes around your queries. If your top query is "posts by user, newest first," you want a composite index (or a partition + clustering key) on (author_id, created_at DESC).

7. Replication

Replication keeps copies of data on multiple machines for availability, durability, and read scaling.

• Leader–follower (primary–replica): one node takes writes, replicas serve reads. Simple, but replicas can lag (stale reads), and failover needs care.
• Multi-leader: multiple nodes accept writes (e.g., one per region). Good for geo-distribution, but you have to resolve write conflicts.
• Leaderless (Dynamo-style): any replica accepts writes; reads and writes use quorums (e.g., with N=3, W=2, R=2, so R + W > N guarantees overlap).

Know synchronous vs asynchronous replication: synchronous is safer but slower; asynchronous is faster but can lose the latest writes on failover.

8. Sharding (Partitioning) and Consistent Hashing

When data or write traffic outgrows one machine, you split it across many. The hard part is picking the shard key.

• Range-based: easy range scans, but risk of hot spots (all new data hits the last shard).
• Hash-based: even distribution, but range queries become scatter-gather.
• Directory-based: a lookup service maps keys to shards. Flexible, but it's another component to keep available.

Consistent hashing solves the "add a server and everything moves" problem. With hash(key) % N, going from 4 to 5 servers remaps about 80% of keys. On a hash ring, only about 1/N of keys move. Virtual nodes smooth out the distribution further. This shows up in caches, Dynamo-style databases, and load balancers. If you want a dedicated walkthrough, I wrote How to Use Consistent Hashing in a System Design Interview.

Always mention hot keys: a celebrity's user ID or a viral post can overload one shard no matter how good your hash function is.

9. CAP and PACELC

CAP: when a network partition happens, a distributed system must choose between consistency (every read sees the latest write, or gets an error) and availability (every request gets a response, possibly stale). You can't skip partitions in a real network, so "CA" isn't a real option for a distributed system.

PACELC extends this: if there's a Partition, choose Availability or Consistency; else (normal operation), choose Latency or Consistency. This is the more useful framing, because your system spends most of its time not partitioned.

The senior move is to choose per feature, not per system. A social app's feed can be AP/EL; the payments for promoted posts in the same app must be CP/EC.

10. Consistency Models

Between "strong" and "eventual" there's a useful middle ground, and naming it precisely is a strong signal:

• Strong (linearizable): every read sees the latest write. Expensive, especially across regions.
• Eventual: replicas converge if writes stop. Cheap and highly available.
• Read-your-writes: a user always sees their own updates (e.g., your own post shows up in your feed immediately), even if others see it a moment later.
• Monotonic reads: a user never sees data go "back in time" between requests.
• Causal: if A caused B (a reply to a comment), everyone sees A before B.

Read-your-writes is the one that saves you in most product designs. Users tolerate others being a few seconds behind; they don't tolerate their own action disappearing. More on this in Consistency Patterns in Distributed Systems.

11. Message Queues and Event-Driven Architecture

Queues decouple producers from consumers. A service publishes an event, and any number of consumers process it at their own pace.

Why they matter in interviews:

• Absorb spikes: the queue buffers bursts that would otherwise overwhelm downstream services.
• Async work: send emails, resize images, update search indexes without blocking the user's request.
• Fan-out: one "OrderPlaced" event feeds inventory, fulfillment, notifications, analytics, and fraud, as in the diagram above.

Know the difference between a queue (SQS, RabbitMQ: each message is processed by one consumer, then deleted) and a log/stream (Kafka, Kinesis: messages are retained and can be replayed by many consumer groups). Know delivery semantics: at-most-once, at-least-once (the common default), and "effectively once" via idempotent consumers. And know back pressure: what happens when consumers can't keep up.

12. Rate Limiting

Rate limiting protects your system from abuse, runaway clients, and (increasingly) runaway AI agents. Common algorithms:

• Token bucket: allows bursts up to the bucket size, then a steady rate. The most common choice.
• Leaky bucket: smooths output to a constant rate.
• Fixed window counter: simple, but allows bursts at window edges.
• Sliding window log/counter: more accurate, a bit more expensive.

In a distributed setup, counters usually live in Redis with atomic operations (or a Lua script). Rate limiting is also a classic standalone interview question; I walk through it in How to Design a Rate Limiter (Step by Step).

13. Idempotency and Retries

Networks fail, clients retry, and at-least-once queues redeliver. Any operation that can be retried must be safe to repeat.

• Have clients send an idempotency key with each write; the server stores the key and the result, and returns the stored result for repeats.
• Make consumers idempotent (e.g., "set status to SHIPPED" instead of "increment shipped count").
• Use exponential backoff with jitter on retries, so a recovering service isn't flattened by a synchronized retry storm.

In any design involving money, orders, or bookings, bring this up before the interviewer does.

14. Unique ID Generation

Auto-increment IDs don't work across shards. Common options:

• UUIDv4: no coordination, but 128 bits, random, and not sortable (bad for B-tree index locality).
• UUIDv7 / ULID: time-ordered, sortable, and no coordination needed.
• Snowflake-style IDs: 64-bit = timestamp + machine ID + sequence. Compact and roughly time-sorted, which makes them perfect as cursors for feeds.

15. Observability and Reliability

You can't operate what you can't see. Mention:

• Metrics: the four golden signals (latency, traffic, errors, saturation), plus business metrics.
• Logs and distributed tracing: to follow one request across many services.
• SLOs: e.g., "99.9% of feed requests under 200 ms." Error budgets tell you when to slow down releases.
• Resilience patterns: timeouts, retries with backoff, circuit breakers, bulkheads, graceful degradation (serve a stale feed rather than an error page).

There are 60+ named patterns in this space. I collected them, with when to use each, in System Design Patterns: The Complete Guide. For a one-page version of this whole toolkit, there's also the System Design Cheat Sheet.

Where to learn these properly: If several of these concepts are new to you, start with Grokking System Design Fundamentals. It covers each building block from scratch. If you know the basics but struggle to apply them under pressure (when to shard, what to cache, how to survive failures), Grokking Scalable Systems for Interviews treats caching, sharding, replication, and fault tolerance as design decisions rather than definitions.

The Trade-offs Interviewers Love to Probe

System design is the art of choosing what to give up. Here are the trade-offs that come up most often, with a one-line rule of thumb for each.

The phrase that signals seniority: "It depends on X. Given our requirement of Y, I'd choose Z, and the cost is W." For a deeper treatment of how to reason through these in the room, see System Design Trade-Offs: How to Navigate Them Like a Senior Engineer.

Full Worked Example: Design a News Feed

Let's put everything together. I'll walk through "Design a news feed" (think Instagram, Facebook, or X/Twitter home timeline) exactly as I'd want a strong senior candidate to do it in 45 minutes. I'll also mark where an L4, L5, and L6 answer would differ.

I picked the news feed because it touches almost every concept above: caching, sharding, queues, fan-out, hot keys, consistency, and ranking. If you can do this one well, you can adapt it to Twitter timelines, notification systems, activity feeds, and more.

Step 1: Requirements

Functional (in scope):

1. Users can create posts (text + optional images/video).
2. Users can follow/unfollow other users.
3. Users see a home feed of posts from people they follow, newest first (with light ranking later).
4. Feed supports infinite scroll.

Out of scope (said out loud): comments, likes, ads, search, stories, DMs.

Non-functional:

• Scale: 500M monthly users, 200M daily active users.
• Latency: feed load p99 < 200 ms.
• Availability: high (99.99%). A slightly stale feed is better than an error.
• Consistency: eventual is fine for followers (a few seconds of delay is OK), but authors must see their own posts immediately (read-your-writes).
• Durability: posts must never be lost.
• Read-heavy: reads far outnumber writes.

Step 2: Estimation

Assumptions (state them, then compute):

• 200M DAU, each opens the feed 5 times/day → 1B feed reads/day.
• 10% of DAU post once a day → 20M new posts/day.
• Average user has ~200 followers; a small number of accounts have millions.
• Post metadata ≈ 1 KB; 20% of posts include media averaging ~500 KB.

Traffic:

• Feed reads: 1B / 10⁵ s ≈ ~12K QPS average, ~35K QPS peak (3×).
• Post writes: 20M / 10⁵ ≈ ~230 QPS average, ~700 QPS peak.
• If we fan out on write: 20M posts × 200 followers = 4B feed inserts/day ≈ 46K/s average. This is the number that should make you pause.

Storage:

• Post metadata: 20M × 1 KB = 20 GB/day ≈ 7 TB/year. Easy.
• Media: 4M × 500 KB = 2 TB/day ≈ 730 TB/year → object storage + CDN, not the database.

Feed cache size:

• Keep the latest 500 post IDs per active user. Each entry ≈ 16 bytes (8-byte ID + 8-byte score) → 8 KB/user.
• 200M users × 8 KB = 1.6 TB raw, maybe 5–8 TB with Redis overhead. That's a large but very normal Redis cluster (dozens of nodes). Capping at 200 entries would cut it by more than half.

What the numbers tell us: reads dominate, so precomputing feeds is worth it. But the fan-out write volume is large and spiky, so it has to be asynchronous, and celebrity accounts need special handling.

L4 vs L5: An L4 candidate often computes QPS and storage and stops. An L5 candidate notices the 46K/s fan-out number and lets it drive the design.

Step 3: API

POST /v1/posts body: { text, media_ids[], idempotency_key } -> 201 { post_id, created_at } GET /v1/feed?cursor={post_id}&limit=20 -> 200 { items: [ { post_id, author, text, media_urls[], created_at } ], next_cursor } POST /v1/users/{user_id}/follow -> 204 DELETE /v1/users/{user_id}/follow -> 204 POST /v1/media/upload-url -> 200 { media_id, presigned_url } // client uploads directly to object storage 

Design notes worth saying out loud:

• Cursor pagination using the last post ID. Offset pagination breaks when new posts arrive at the top while you scroll.
• Idempotency key on post creation so a flaky mobile network doesn't create duplicate posts.
• Pre-signed upload URLs so large media goes straight to object storage, not through our app servers.

Step 4: Data Model

Post IDs are Snowflake-style 64-bit IDs: time-sortable, unique across shards, and directly usable as feed scores and pagination cursors.

Step 5: High-Level Design

Source：https://dev.to/arslan_ah/the-2027-system-design-interview-playbook-framework-concepts-and-a-full-worked-example-2mn6