Learn system design by scaling one app 📈

Always walk the same six steps, out loud. Clarify what we're building, estimate how big, sketch the API, draw the boxes, then zoom into one hard part, then hunt for what breaks. The order matters: each step feeds the next.

Now the words: steps 1-2 define functional and non-functional requirements. Step 4 is your high-level architecture. Step 6 is finding the single point of failure and the bottleneck.

Estimate three things: traffic per second, how much you store, and how much data moves over the wire. Round hard. The goal is the right power of ten, not a spreadsheet.

Split requirements into two piles. Functional = the features (send, receive, history, presence). Non-functional = the qualities (fast, always up, durable, scales). Then promise a number for the qualities so everyone agrees what "good" means.

Now the words: SLI is the indicator (measured), SLO is the objective (target), SLA is the agreement (contractual, with consequences). SLI ⊂ SLO ⊂ SLA.

Two ways to grow. Vertical = make the one machine bigger (more CPU/RAM). Simple, but there's a ceiling and it's a single point of failure. Horizontal = add more machines and split the work. Nearly unlimited, survives failures, but only works if each machine is stateless (keeps no session in local memory, so any machine can serve any request).

Now the words: vertical = scale up, horizontal = scale out. A machine holding no local session is a stateless service. The shared store is where the state lives.

Put a load balancer in front. Every request hits it first, and it forwards to a healthy backend. It constantly health-checks the servers and quietly stops sending traffic to dead ones. It's also your public front door, so clients never see individual servers.

Now the words: spreading requests uses an algorithm: round-robin (take turns), least-connections (fewest busy), or IP-hash (same client → same server). L4 routes on IP/port; L7 reads the HTTP request and routes on content.

A cache is a small, fast store of copies of hot data. Check it first; only touch the slow database on a miss. Caches live at every layer: the browser, a CDN near the user, a shared server-side cache like Redis, and inside the DB itself.

Now the words: found in cache = hit, not found = miss. Kicking out old entries = eviction. Time-to-live = TTL. Least-recently-used = LRU.

Pick storage by shape. SQL (Postgres, MySQL) = rigid tables, joins, transactions, strong guarantees. Great for users, payments, anything relational. NoSQL (Cassandra, DynamoDB, Mongo) = flexible, spreads across many machines easily, huge write volume. Great for the message firehose. Either way, add an index on the columns you search by so lookups are instant instead of full scans.

Now the words: ACID = Atomic, Consistent, Isolated, Durable (SQL's promise). NoSQL families: key-value, document, wide-column, graph. An index is usually a B-tree or hash structure.

Replication makes copies: one leader takes writes, several followers copy it and serve reads. Spreads read load and gives you a spare if the leader dies. Sharding splits the data itself across machines, each shard holds a slice, so total size and write load scale out.

Now the words: leader-follower is also called primary-replica. Copying is replication (sync = wait for followers, async = don't). Splitting = sharding / partitioning. The column you split on = shard key / partition key.

When the network splits (a partition, the P), a distributed system can keep only one of two things: every node agrees on the same latest data (Consistency), or every request still gets an answer (Availability). You must choose CP or AP for that moment. You can't skip P; networks do fail.

Now the words: CAP = Consistency, Availability, Partition-tolerance. During a partition you get CP or AP. PACELC adds the normal-time trade: Else Latency vs Consistency.

Strong = every read sees the latest write, always. Safe, but slower and less available. Eventual = reads may lag briefly, then catch up. Faster and more available. The useful middle: read-your-writes, which guarantees you always see your own changes even if others lag.

Put a queue between the fast part (accept the message, reply "got it") and the slow parts (LLM, push, moderation). The producer drops a message on the queue; consumers pull and process at their own pace. Spikes just make the queue longer instead of losing work. Many consumers can subscribe (pub/sub).

Now the words: Kafka (log, replayable, high throughput), SQS/RabbitMQ (task queues). Sender = producer, reader = consumer, broadcast-to-many = pub/sub. Same input, same result = idempotent.

Pick a style. REST = simple URLs and verbs over HTTP, universal, easy to cache. gRPC = fast binary, strict contracts, great between your own services. GraphQL = client asks for exactly the fields it wants in one call, great for varied clients. Then handle the basics: page large lists, version so you can evolve, and use idempotency keys so a retried "send" doesn't duplicate.

Now the words: an idempotency key is a unique id the client sends with a write so the server dedupes retries. REST resources use HTTP verbs (GET/POST/PUT/DELETE). gRPC uses protobuf over HTTP/2.

Count each caller's requests and reject once they exceed a limit. Token bucket allows bursts up to the bucket size, then throttles to the refill rate, this is what most APIs use. Leaky bucket instead drains at a fixed, smooth rate no matter the input, good when the downstream needs a steady stream.

Now the words: rejected requests get HTTP 429 Too Many Requests. Limits are keyed per user / IP / API key. In a fleet, the counter lives in a shared store (Redis) so all servers agree.

Map both servers and keys onto a ring (a circle of hash values). A key belongs to the first server clockwise from it. When a server joins or leaves, only the keys in its immediate arc move, not the whole cache. Add virtual nodes (each server sits at many points) so the load spreads evenly.

Now the words: the circle is the hash ring. Extra placements per server are virtual nodes (vnodes), they smooth out uneven load.

Build in defenses. Retries handle blips, but use exponential backoff + jitter (wait longer each time, with randomness) so you don't stampede. A circuit breaker stops calling a service that's clearly down and fails fast. Bulkheads isolate resources so one drowning feature can't sink the rest. Always set timeouts, never wait forever.

Now the words: redundancy = spare copies; failover = switch to the spare automatically. Bulkhead = separate thread/connection pools per dependency. Circuit breaker states: closed → open → half-open.

Instrument three things. Logs = timestamped text of individual events. Metrics = numbers over time (QPS, latency, error rate) you graph and alert on. Traces = follow one request across every service it touches, so you see exactly which hop was slow.

Now the words: the three together are the three pillars of observability. A trace is made of spans (one per hop). p99 = the latency 99% of requests beat.

A monolith is one deployable app: simple, fast to build, great early. Microservices split it into independent services (auth, chat, search, billing), each owned by a team, deployed and scaled alone. The catch: a business action now spans services, so you can't use one database transaction.

Now the words: start with a modular monolith; split only when team or scale pain is real. Cross-service consistency uses sagas and compensating transactions, not distributed 2-phase commit (fragile).

Two distinct steps. Authentication (authn) proves identity, usually a login that returns a token. Authorization (authz) checks permissions on every request. Encrypt data in transit with TLS and at rest on disk. Keep passwords hashed and secrets out of code. Layer defenses so one failure isn't fatal.

Now the words: JWT = a signed token the client carries proving who they are. OAuth2 = the delegated "log in with Google" flow. TLS = the S in HTTPS. authn ≠ authz: identity vs permission.

1. Clarify: shorten a URL, redirect fast, optional custom alias + analytics. Read-heavy (people click far more than they create).

2. Estimate: 100M new URLs/month ≈ 40 writes/s. Read:write ~100:1 → ~4,000 reads/s. 100M × 500 bytes × 12 months ≈ 0.6 TB/yr. Small data, huge read traffic → cache hard.

3. API: POST /urls {long_url} → {short}. GET /{short} → 301 redirect. Idempotency key on create.

4. Encoding: take a unique 64-bit id from a counter/Snowflake, base62 encode it (a-z A-Z 0-9) → a 7-char code covers 62⁷ ≈ 3.5 trillion. Avoids the collision checks a random hash needs.

5. Schema: short_code (PK) · long_url · created_at · owner. A key-value store is ideal: lookup by code is a single get.

6. Scale & bottlenecks: shard the KV store by short_code (consistent hashing). Cache hot codes in Redis + CDN so 90%+ of redirects never hit the DB. Redirects are stateless, so scale app servers horizontally behind the LB.

1. Two pipelines. Ingestion (offline): documents → chunk → embed → store vectors. Query (online): user question → embed → retrieve similar chunks → stuff into the prompt → LLM → stream answer. RAG = give the model the right context so it answers from facts, not memory.

2. Vector store & retrieval: store embeddings in a vector DB (Pinecone, pgvector, Milvus). At query time, embed the question and fetch the top-k nearest chunks (approximate nearest neighbor, ANN). Keep each tenant in its own namespace so no one retrieves another company's docs.

3. LLM gateway: a single choke point in front of all model calls. It handles model routing (cheap model for easy questions, strong for hard), fallback if a provider is down, retries with backoff, token/cost accounting, and streaming responses back to the user token by token.