کارگاهِ طراحیِ سیستم: مثال‌های واقعیSystem Design Walkthroughs

Let me start with a truth many people learn too late: a system design interview is not a knowledge test — it is a judgment test. The interviewer does not want to see that you can name ten databases; they want to see how you take a vague, unbounded problem and break it into buildable pieces, what you ask, where you make trade-offs, and whether you understand the cost of every decision.

Here is what separates an experienced mid-level engineer from a senior. The mid-level says "we'll use Kafka because it's scalable." The senior says "Kafka makes the read path async here and raises throughput, but ordering is only guaranteed per-partition, so if I need global ordering I'd have to change the key or use a single partition — which is itself a bottleneck — and since I won't accept that trade-off, I'll solve ordering at the business level with a version number." Same decision, but with full awareness of the cost.

This chapter is a workshop. We fully design six real systems — the ones actually asked in senior interviews and actually built in production. For each we walk the same path, and along the way we practice the language a senior uses to narrate decisions.

The repeatable interview framework (seven steps)

Before any design, keep this map in mind. Whatever you call it (some call it RESHADED or PEDALS) doesn't matter; what matters is that you always start from step one, not the middle. The biggest candidate mistake: the interviewer says "design a URL shortener" and the candidate immediately jumps to "I'll use Cassandra." That means you didn't understand the problem.

Step 1 — Clarify requirements (functional & non-functional). Spend a few minutes asking. Functional is "what the system does" (shorten a link, redirect). Non-functional is "how well it does it" (what latency? what availability? how much consistency?). These, not the features, drive the architecture.

Step 2 — Estimate scale (back-of-envelope). QPS, data volume, bandwidth, memory. It needn't be exact; the order of magnitude must be right. The difference between 100 QPS and 100,000 QPS completely changes the architecture.

Step 3 — Design the API. The external contract. Endpoints, methods, parameters. This forces you to think precisely about what the system actually offers.

Step 4 — Data model and storage choice. What entities? SQL or NoSQL? Why? Index on what?

Step 5 — High-level architecture. One diagram: client → LB → service → cache → DB. Main components and data flow.

Step 6 — Deep-dive on one or two hard spots. The interviewer usually probes a specific area: "how do you generate unique IDs?", "what about the celebrity?". Here you show your depth.

Step 7 — Bottlenecks, scale, trade-offs. Where is the single point of failure? How do you scale? What did you trade for what?

Back-of-envelope estimation: the numbers you must know

Estimation isn't scary if you memorize a few base numbers. The whole trick: convert monthly/daily into per-second, separate reads from writes, and derive memory/bandwidth from QPS.

Conversion rule: if you have X requests per day, average QPS ≈ X / 10⁵. E.g. 100 million/day → 10⁸/10⁵ = 1000 QPS average, peak ~2–3k.

Latency numbers seniors reason with (the classic "Latency Numbers Every Programmer Should Know", orders of magnitude):

Design 1 — URL Shortener

The most classic question, and deceptive: it looks simple but has deep points (unique ID generation, being read-heavy, mapping durability).

Step 1 — Requirements

Functional: (1) give a long URL, get a short code. (2) redirect from short code to the original. (3) optional: custom alias, expiry (TTL), click analytics. Non-functional: (1) redirect must be very fast (low latency). (2) read-heavy: read-to-write ratio around 100:1 or higher (a link is created once, opened thousands of times). (3) codes unique and (somewhat) unguessable. (4) high availability; if redirect fails, every link breaks.

Step 2 — Estimation

Assume 100 million new links per month. Write QPS = 10⁸ / 2.5×10⁶ ≈ 40/s. With read:write = 100:1 → reads ≈ 4000/s (peak ~10k). Over 5 years: 10⁸ × 60 months = 6 billion records. Each record ~500 bytes (code + URL + metadata) → ~3TB of raw data, with overhead and replication ~10TB. This is "large but not gigantic"; a well-sharded database suffices.

Step 3 — API

POST /api/v1/urls
  body: { "longUrl": "https://...", "customAlias": "promo", "ttlDays": 30 }
  201 -> { "shortUrl": "https://sho.rt/aX9bQ2", "code": "aX9bQ2" }

GET /{code}
  302 Found, Location: <longUrl>   // redirect

A subtle point: 302 (temporary) or 301 (permanent)? A senior notes that browsers cache 301 and stop hitting your server — great for load, terrible for click analytics. So if you want analytics, use 302 (or 307) so every click reaches you.

Step 4 — Data model

A simple key-value: key = code, value = longUrl + metadata. For this workload PostgreSQL is entirely enough (into the billions with sharding); but if writes become truly massive, a key-value store like Cassandra/DynamoDB is reasonable.

-- PostgreSQL
CREATE TABLE url_map (
    code        VARCHAR(11) PRIMARY KEY,
    long_url    TEXT        NOT NULL,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
    expires_at  TIMESTAMPTZ,
    owner_id    BIGINT
);
CREATE INDEX idx_url_map_expires ON url_map (expires_at) WHERE expires_at IS NOT NULL;

-- Oracle
CREATE TABLE url_map (
    code        VARCHAR2(11) PRIMARY KEY,
    long_url    CLOB         NOT NULL,
    created_at  TIMESTAMP    DEFAULT SYSTIMESTAMP NOT NULL,
    expires_at  TIMESTAMP,
    owner_id    NUMBER
);
CREATE INDEX idx_url_map_expires ON url_map (expires_at);

ID generation — the heart of the design

Three approaches:

Approach 1: hash (MD5/SHA) and take a few chars. Simple, but has collisions you must check — meaning an extra read per write. Same URL always maps to the same code (idempotent), which is nice, but collision handling is a hassle.

Approach 2: global counter + Base62. Take an auto-increment number and convert to Base62 (0-9a-zA-Z, 62 chars). With 7 chars: 62⁷ ≈ 3.5 trillion codes. Problem: a global counter is a single point of contention. Solution: range allocation — each instance grabs a range (say 1000) from a central service and consumes it locally, only hitting the center once per 1000.

Approach 3: Snowflake ID. A unique 64-bit number without coordination: timestamp + machine id + sequence. We build this below.

// Snowflake-style 64-bit unique ID generator (Twitter-inspired)
// layout: 1 unused sign bit | 41 timestamp bits | 10 machine bits | 12 sequence bits
public final class SnowflakeIdGenerator {

    private static final long EPOCH = 1704067200000L; // 2024-01-01, custom epoch

    private static final long MACHINE_BITS  = 10L;
    private static final long SEQUENCE_BITS = 12L;

    private static final long MAX_MACHINE_ID = (1L << MACHINE_BITS) - 1;   // 1023
    private static final long MAX_SEQUENCE   = (1L << SEQUENCE_BITS) - 1;  // 4095

    private static final long MACHINE_SHIFT    = SEQUENCE_BITS;                // 12
    private static final long TIMESTAMP_SHIFT  = SEQUENCE_BITS + MACHINE_BITS; // 22

    private final long machineId;
    private long lastTimestamp = -1L;
    private long sequence = 0L;

    public SnowflakeIdGenerator(long machineId) {
        if (machineId < 0 || machineId > MAX_MACHINE_ID) {
            throw new IllegalArgumentException("machineId out of range: " + machineId);
        }
        this.machineId = machineId;
    }

    public synchronized long nextId() {
        long now = System.currentTimeMillis();
        if (now < lastTimestamp) {
            // clock moved backwards (NTP correction) -> refuse to hand out risky ids
            throw new IllegalStateException("Clock moved backwards by "
                    + (lastTimestamp - now) + " ms");
        }
        if (now == lastTimestamp) {
            sequence = (sequence + 1) & MAX_SEQUENCE;
            if (sequence == 0) {           // 4096 ids exhausted this ms -> wait next ms
                now = waitNextMillis(lastTimestamp);
            }
        } else {
            sequence = 0L;
        }
        lastTimestamp = now;
        return ((now - EPOCH) << TIMESTAMP_SHIFT)
                | (machineId << MACHINE_SHIFT)
                | sequence;
    }

    private long waitNextMillis(long last) {
        long ts = System.currentTimeMillis();
        while (ts <= last) { ts = System.currentTimeMillis(); }
        return ts;
    }
}

Then we Base62-encode that long into the short code:

public final class Base62 {
    private static final String ALPHABET =
        "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
    private static final int BASE = ALPHABET.length(); // 62

    public static String encode(long value) {
        if (value == 0) return "0";
        StringBuilder sb = new StringBuilder();
        while (value > 0) {
            sb.append(ALPHABET.charAt((int) (value % BASE)));
            value /= BASE;
        }
        return sb.reverse().toString();
    }
}

Architecture

Diagram: the write and read paths of the URL shortener (English labels, create + redirect).

flowchart LR
  Client -->|POST create| LB[Load Balancer]
  Client -->|GET code| LB
  LB --> App[Shortener Service]
  App -->|nextId + base62| IDGen[Snowflake / Counter]
  App -->|read-through| Cache[(Redis Cache)]
  App --> DB[(URL Store - sharded)]
  Cache -.miss.-> DB
  App -->|click event| MQ[(Kafka - analytics)]

The critical point: since it's read-heavy, redirects must come from cache, not the database. Put a Redis in front with code -> longUrl. A high hit rate (popular links stay hot) means most redirects are under 1ms.

Design 2 — Distributed Rate Limiter

Every serious system needs a rate limiter: to stop abuse, DDoS, and unfair usage, and to protect downstream services from overload.

Step 1 — Requirements

Functional: for a given key (userId/IP/apiKey), allow at most N requests in window T. Beyond that, return 429 Too Many Requests with a header like Retry-After. Non-functional: (1) very low latency — the rate limiter is on the hot path of every request, so it must not be slow. (2) distributed: multiple service instances, but the limit must be global (a user must not consume N times as much by hitting different instances). (3) accuracy: a little error is acceptable, but not catastrophic.

Algorithms — the real trade-off

Local implementation with Bucket4j (single instance)

For a single instance, Bucket4j (a Java library based on token bucket) is excellent:

// build.gradle: implementation 'com.bucket4j:bucket4j_jdk17-core:8.16.1'
import io.github.bucket4j.Bandwidth;
import io.github.bucket4j.Bucket;

public Bucket newBucket() {
    // 100 requests capacity, refill 100 tokens every minute
    Bandwidth limit = Bandwidth.builder()
            .capacity(100)
            .refillGreedy(100, Duration.ofMinutes(1))
            .build();
    return Bucket.builder().addLimit(limit).build();
}

// in a filter:
Bucket bucket = cache.computeIfAbsent(apiKey, k -> newBucket());
if (bucket.tryConsume(1)) {
    chain.doFilter(request, response);   // allowed
} else {
    response.setStatus(429);
    response.setHeader("Retry-After", "60");
}

Distributed implementation with Redis + Lua (atomic)

For multiple instances, state must be shared and the "read-decide-write" cycle must be atomic, or a race condition lets two concurrent requests both get through. The professional way: a Lua script Redis executes atomically.

-- token bucket in Redis, atomic via EVAL
-- KEYS[1] = bucket key
-- ARGV[1] = capacity, ARGV[2] = refill_per_sec, ARGV[3] = now_ms, ARGV[4] = requested
local capacity   = tonumber(ARGV[1])
local refill     = tonumber(ARGV[2])
local now        = tonumber(ARGV[3])
local requested  = tonumber(ARGV[4])

local data   = redis.call('HMGET', KEYS[1], 'tokens', 'ts')
local tokens = tonumber(data[1])
local ts     = tonumber(data[2])
if tokens == nil then tokens = capacity; ts = now end

-- refill based on elapsed time
local delta = math.max(0, now - ts) / 1000.0
tokens = math.min(capacity, tokens + delta * refill)

local allowed = 0
if tokens >= requested then
  tokens = tokens - requested
  allowed = 1
end

redis.call('HMSET', KEYS[1], 'tokens', tokens, 'ts', now)
redis.call('PEXPIRE', KEYS[1], 60000)   -- TTL so idle keys vanish
return allowed

From Spring:

@Component
public class RedisRateLimiter {
    private final StringRedisTemplate redis;
    private final RedisScript<Long> script; // loads the Lua above

    public boolean allow(String key, int capacity, int refillPerSec) {
        Long ok = redis.execute(
            script,
            List.of("rl:" + key),
            String.valueOf(capacity),
            String.valueOf(refillPerSec),
            String.valueOf(System.currentTimeMillis()),
            "1");
        return ok != null && ok == 1L;
    }
}

Design 3 — News Feed / Timeline (fan-out)

A popular question because its hard core is a beautiful trade-off: fan-out on write vs fan-out on read.

Step 1 — Requirements

Functional: a user posts; followers see it in their timeline (ordered, usually newest-first or ranked). Non-functional: (1) reading the feed must be fast (users won't wait). (2) heavily read-heavy. (3) eventual consistency is fine — if a friend's post arrives a few seconds late, no disaster.

Step 2 — Estimation

Assume 500 million daily users, each opening the feed 20 times/day → 10 billion reads/day ≈ 10¹⁰/10⁵ = 10⁵ = 100k read QPS. Post writes are far fewer (maybe 10 million posts/day ≈ ~100/s). This huge read:write ratio drives the main decision.

The two main strategies

Fan-out on write (push): at post time, you write the post into every follower's timeline (usually a per-user cache in Redis). Reading the feed becomes fast (just read your own timeline), but writing is heavy.

Fan-out on read (pull): you store the post in just one place. At read time, you gather and merge posts from everyone you follow. Writing is light, but reading is heavy and slow.

Diagram: the two fan-out strategies (write immediately into followers' timelines vs gather at read time).

flowchart TD
  subgraph Write[Fan-out on Write]
    A[User posts] --> B[Post Service]
    B --> C{For each follower}
    C --> D[(Follower timeline cache)]
  end
  subgraph Read[Fan-out on Read]
    E[User opens feed] --> F[Feed Service]
    F --> G[Fetch followees' posts]
    G --> H[Merge + rank at read time]
  end

The celebrity problem and the hybrid solution

Here the trade-off comes alive. If a celebrity with 50 million followers posts, fan-out on write means 50 million writes for a single post — saturating the write path for seconds (the "hot key problem"). This is exactly the problem Twitter's team fought for years.

The senior approach: hybrid. Regular users (below ~10k followers) → fan-out on write (write into timelines). Celebrities → fan-out on read (their posts stored separately, no fan-out). At read time, the pre-computed timeline (from regular users) is merged with a real-time fetch of the posts of the celebrities you follow.

Design 4 — Chat / Messaging (delivery and presence)

A messenger is real-time and has its own problems: a persistent connection, guaranteed delivery, ordering, and presence (online/offline).

Step 1 — Requirements

Functional: (1) 1-to-1 and group messages. (2) delivery status (sent/delivered/read). (3) presence (who's online). (4) message history. Non-functional: (1) low latency (real-time). (2) reliable delivery — no message lost. (3) within-conversation ordering preserved.

Why WebSocket, not HTTP polling

HTTP request/response is bad for real-time messaging: you either poll constantly (wasteful) or long-poll (heavy). WebSocket gives a persistent bidirectional connection; the server can push without the client asking. In Spring, WebSocket + STOMP is standard.

@Configuration
@EnableWebSocketMessageBroker
public class WsConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/ws")
                .setAllowedOriginPatterns("https://app.example.com")
                .withSockJS(); // fallback for old browsers
    }

    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {
        // for a single node the simple broker is fine;
        // for a cluster relay to RabbitMQ/ActiveMQ STOMP broker instead
        registry.enableSimpleBroker("/topic", "/queue");
        registry.setApplicationDestinationPrefixes("/app");
        registry.setUserDestinationPrefix("/user"); // per-user private queues
    }
}

Reliable delivery and ordering

A message must not be lost even if the recipient is offline. Pattern: the message is first persisted to the database (source of truth), then pushed. If the recipient was offline, on their next connect they pull pending messages from the database. For ordering, each message has a conversation-level sequence number.

Diagram: the path of sending a message with persist-then-push (store before delivery, offline delivery from the database).

sequenceDiagram
  participant A as Sender
  participant S as Chat Service
  participant DB as Message Store
  participant B as Receiver
  A->>S: send(msg, convId)
  S->>DB: persist(msg, seq)
  DB-->>S: ok (source of truth)
  S-->>A: ack (sent)
  alt receiver online
    S->>B: push(msg)
    B-->>S: delivered
  else receiver offline
    Note over S,B: stored — delivered on next connect
  end

Presence (online/offline)

Presence is harder than it looks. The simplest way: each client sends a heartbeat every few seconds; the server keeps the last heartbeat in Redis with a TTL. If the TTL expires, the user is offline.

// on each heartbeat / activity
redis.opsForValue().set("presence:" + userId, "online",
        Duration.ofSeconds(30));   // key auto-expires if no heartbeat
// to check:
boolean online = redis.hasKey("presence:" + userId);

Design 5 — Notification System

Notifications (push/SMS/email/in-app) are infrastructure almost every product needs, with many subtleties: multiple channels, rate limiting, priority, and idempotency.

Step 1 — Requirements

Functional: (1) send over multiple channels: push (APNs/FCM), SMS, email, in-app. (2) templates. (3) user preferences (opt-out per channel). (4) priority (transactional like OTP vs marketing). Non-functional: (1) reliable — an OTP must not be lost. (2) scale — millions of notifications. (3) no duplicate notifications (idempotency). (4) no spam (rate limit per user).

Architecture — decoupling with a queue

The core of the design: async with a message queue. A service wanting to send a notification just drops an event in a queue and returns; workers do the actual sending. This decouples the producer from the slowness/failure of providers.

Diagram: notification system architecture with a queue and per-channel workers (producer decoupled from delivery, each channel an independent worker).

flowchart LR
  Svc[Any Service] -->|notify event| Q[(Kafka / Queue)]
  Q --> Router[Notification Router]
  Router -->|check prefs + rate limit| Prefs[(Preferences DB)]
  Router --> PushW[Push Worker] --> FCM[FCM / APNs]
  Router --> SmsW[SMS Worker] --> Twilio[SMS Provider]
  Router --> MailW[Email Worker] --> SES[Email Provider]
  Router --> Dedup[(Dedup / Idempotency Store)]

Idempotency — the heart of reliability

If the producer, due to a retry, sends an event twice, the user must not get two OTPs. Each notification has a unique idempotencyKey; before sending, the worker checks whether this key was already processed (in Redis with a TTL).

public void handle(Notification n) {
    // SETNX-style: only the first caller wins
    Boolean fresh = redis.opsForValue()
        .setIfAbsent("notif:" + n.idempotencyKey(), "1", Duration.ofHours(24));
    if (Boolean.FALSE.equals(fresh)) {
        log.info("duplicate notification {}, skipping", n.idempotencyKey());
        return;                       // already sent
    }
    channelFor(n.channel()).send(n); // send exactly once (effectively)
}

Design 6 — E-commerce Order Flow (across services)

This design brings it all together: multiple services, a distributed transaction, consistency, and compensation. This is where understanding saga and outbox shows its worth.

Step 1 — Requirements

Functional: a customer checks out; the system must: (1) reserve inventory (Inventory), (2) capture payment (Payment), (3) record the order (Order), (4) start shipping (Shipping), (5) send notifications. Non-functional: (1) consistency: you must not charge money without inventory, or reserve inventory without capturing payment. (2) reliable and retryable. (3) traceable (where in the flow are we).

The core challenge — a transaction across services

In a monolith, these were one @Transactional and everything was atomic. But each service has its own database; there is no global ACID transaction (2PC is slow, fragile, and avoided at scale). Solution: saga — a sequence of local transactions, each publishing an event; if a step fails, prior steps are undone via a compensating transaction.

Orchestration vs Choreography

Two saga styles:

• Choreography: each service listens to others' events and reacts; no central control. Simple for short flows, but for long flows it becomes hard to know "where are we now" (logic scattered everywhere).
• Orchestration: a central orchestrator (e.g. the Order Service or a state machine) drives the steps and knows where you are. Better for complex multi-step flows because the logic is in one place and tracing is easy.

Diagram: the lifecycle of an order as a state machine (order states and the compensation path on failure).

stateDiagram-v2
  [*] --> Created
  Created --> InventoryReserved: reserve ok
  InventoryReserved --> PaymentCaptured: payment ok
  PaymentCaptured --> Confirmed: order confirmed
  Confirmed --> Shipped: shipping started
  Shipped --> [*]
  InventoryReserved --> Cancelled: payment failed / compensate release stock
  PaymentCaptured --> Refunding: downstream failed / refund
  Refunding --> Cancelled
  Created --> Cancelled: out of stock

The dual-write problem and the Outbox solution

Here is the subtlest bug in event-driven systems. The Order Service wants to both write to its own database (order recorded) and send an event to Kafka (so downstream services find out). If you write to the DB first and then send to Kafka, and crash in between? The order is recorded but nobody was notified — a "lost order." If you reverse it, the event went out but the order wasn't recorded — an event for an order that doesn't exist.

Solution: Transactional Outbox. Write the event, in the same database transaction, into an outbox table. Since both writes are in one local ACID transaction, either both happen or neither. Then a separate process (polling, or CDC like Debezium) reads the outbox table and publishes to Kafka.

@Transactional
public Order placeOrder(OrderRequest req) {
    Order order = orderRepository.save(Order.created(req));   // write 1
    OutboxEvent evt = OutboxEvent.of(
        "OrderCreated", order.getId(), toJson(order));
    outboxRepository.save(evt);                               // write 2 -- SAME tx
    return order;
    // both commit atomically; a separate relay ships evt to Kafka later
}

-- PostgreSQL: outbox table
CREATE TABLE outbox (
    id            BIGSERIAL PRIMARY KEY,
    aggregate_id  BIGINT      NOT NULL,
    event_type    VARCHAR(64) NOT NULL,
    payload       JSONB       NOT NULL,
    created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
    published     BOOLEAN     NOT NULL DEFAULT false
);

-- Oracle: outbox table
CREATE TABLE outbox (
    id            NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    aggregate_id  NUMBER        NOT NULL,
    event_type    VARCHAR2(64)  NOT NULL,
    payload       CLOB          NOT NULL,   -- or JSON type in 21c+
    created_at    TIMESTAMP     DEFAULT SYSTIMESTAMP NOT NULL,
    published     NUMBER(1)     DEFAULT 0 NOT NULL
);

The language of trade-off narration: how a senior thinks out loud

So far we've built six systems. But what marks you as a senior in an interview isn't the design itself — it's how you talk about it. Here are the linguistic patterns seniors use:

1) Always put the cost next to the benefit. Never just say "I'll add a cache." Say "a cache lowers latency but introduces a consistency problem (stale data) and a new failure layer — and I accept this trade-off because this data is read-heavy and a few seconds of staleness is fine." The structure: "I'll choose X, which improves Y at the cost of Z, and Z is acceptable here because W."

2) Talk explicitly about CAP and consistency. Say where strong consistency is needed (payment, inventory) and where eventual is enough (feed, like count). This shows you understand you can't have strong everywhere.

3) Find the bottleneck before the interviewer does. After drawing the architecture, say yourself: "the single point of failure here is Redis; if it goes down, this happens, and the mitigation is this." Proactively naming weaknesses builds trust.

4) Describe scaling incrementally. "For V1, one PostgreSQL suffices. When we hit X QPS, I add a read replica. When writes also bottleneck, I shard on this key." This shows you don't over-engineer and you see the growth path.