System Design Series: The Conclusion

Sixty-five posts ago, we started with a simple question: what happens when you type a URL and press Enter?

Since then, we have followed data packets across the internet. We learned how databases keep data safe and how to split data across machines. We sent messages through queues and learned how to survive failures. We watched systems with logs and traces, protected them from attackers, and released them safely. Last, we designed complete systems like chat apps and news feeds.

This final post brings it all together:

• what each series taught us, in one line each,
• the 20 principles that matter most,
• a checklist you can use for any design,
• and what to do next.

If you forget everything else, remember these.

Thinking

1. Requirements first. Write down what the system does, what it doesn't do, and how well it must do it (in numbers).
2. Estimate before you design. Make a rough guess of the load. "40 writes per second" and "40,000 writes per second" need completely different systems.
3. There's no perfect design, only trade-offs. Say what you gain and what you give up.
4. Start simple. A well-tuned monolith (one application) and one database can go very far. Add complexity only when the numbers demand it.
5. Design for your next 12–24 months, with a clear path to grow, not for Google's scale on day one.

Data

6. Pick the data model from the access patterns (how your code reads and writes the data), not from hype. PostgreSQL (a relational database) plus Redis (a fast in-memory store) is a strong default.
7. Decide consistency for each feature. Money and uniqueness need strong consistency, which means every reader sees the latest data. Likes and feeds can be eventually consistent, which means copies may differ for a short time and then agree.
8. Replication is for availability and reads. Sharding is for writes and size. Backups are for going back in time. Replication keeps extra copies of data on other machines. Sharding splits data across machines. A backup is a saved copy from an earlier moment. You will need all three, in time.
9. Choose shard keys and IDs carefully. A shard key is the field that decides which machine holds a row. It is very hard to change later.
10. Cache a lot, but plan for stale data, stampedes and cache failure. A cache is a fast copy of data. Stale means old. A stampede is when many requests miss the cache together and hit the database.

Communication

11. Make every write safe to retry. Idempotency means doing an action twice has the same result as doing it once. Use idempotency keys (a unique ID sent with each request), unique constraints and dedup (removing duplicates).
12. Use queues for work the user doesn't need to wait for, and expect messages to arrive more than once.
13. Treat APIs and events as contracts. Add fields freely; never break existing clients without a plan.

Reliability

14. Every network call needs a timeout (a limit on how long you wait). Allow only a few retries, with backoff and jitter: wait longer after each try, plus a random extra time. Also have a plan for when the other side is down.
15. Remove single points of failure, spread across zones, and test failover and restores regularly.
16. Protect yourself from overload. Use rate limits (a cap on requests per client). Use load shedding (refuse some requests on purpose) and graceful degradation (turn off less important features) to keep the system alive.

Operations and security

17. Measure what users experience: SLOs, p99 latency and error budgets. p99 latency is the time that 99 of 100 requests beat. An error budget is how much failure your SLO still allows. Alert on symptoms that users feel, not on noise.
18. Most outages start with a change, so deploy in small steps, gradually and reversibly. A canary sends a new version to a few users first. A feature flag turns a feature on or off without a deploy.
19. Security basics beat clever tricks. Authorise every object. Parameterise queries (send user input as data, never as SQL code). Patch dependencies. Keep secrets out of code. Encrypt everywhere.
20. Learn blamelessly. Write postmortems (reports about an outage), share them, and fix the system instead of blaming a person.

Use this for interviews, design documents or real projects.

1. Requirements

• ☐Core use cases (3–5), and what's out of scope
• ☐Users, scale, growth, read/write ratio
• ☐Latency targets (p99), availability target, durability needs
• ☐Consistency needs per feature
• ☐Security, privacy, compliance and budget constraints

2. Estimation

• ☐Average and peak QPS (queries per second; count reads and writes separately)
• ☐Storage over time (and media vs metadata)
• ☐Bandwidth, cache size and server count
• ☐"So this means…" conclusions

3. API and data

• ☐Main endpoints / events, including idempotency, pagination and auth
• ☐Core entities and access patterns
• ☐Storage choice for each type of data
• ☐IDs, keys and (future) shard keys

4. High-level design

• ☐Clients → DNS/CDN → load balancer / gateway → services → cache / DB / storage
• ☐Sync vs async paths (queues, workers)
• ☐Each use case walked through the diagram

5. Deep dives

• ☐Bottlenecks at 10× and 100×: caching, replicas, sharding, queues
• ☐Failure handling: timeouts, retries, circuit breakers, fallbacks, load shedding
• ☐Correctness: transactions, idempotency, ordering, duplicates
• ☐Hot keys, celebrities and spikes
• ☐Security: authN/authZ, secrets, encryption, abuse and rate limits
• ☐Observability: SLIs (the measured numbers) and SLOs (the goals for them), dashboards, alerts
• ☐Deployment: CI/CD, canaries, rollback, database migrations
• ☐Backups and disaster recovery (RPO is how much data you can afford to lose; RTO is how long you can be down)

6. Wrap-up

• ☐Key decisions and trade-offs
• ☐Risks and what you'd monitor
• ☐Next steps and how it evolves

Here is the "big picture" in one small diagram. (The companion reference post, "The Complete System Design Architecture", goes through every layer in detail.)

Every case study in Part 11 was a variation of this picture, with a different emphasis:

• URL shortener: reads and caching.
• Rate limiter: fast shared counters.
• Notifications: queues and third-party providers.
• Chat: persistent connections and ordered storage.
• News feed: fan-out and ranking.

• ❌ Buzzword architecture: Kafka, Kubernetes and microservices without a reason.
• ❌ Designing without numbers.
• ❌ Ignoring failure: assuming every dependency is always up and fast.
• ❌ Treating replication as backup. Replication copies mistakes too. If you delete a table, the replicas delete it as well.
• ❌ Using averages instead of percentiles. An average hides slow requests. A percentile such as p99 shows them.
• ❌ Unsafe retries that double-charge customers.
• ❌ Logging secrets, or trusting the client.
• ❌ Big-bang releases and big-bang rewrites (changing everything at once).
• ❌ Blaming people instead of fixing systems.

1. Build something small, end to end. A URL shortener or a chat app with WebSockets, Redis and PostgreSQL, running in Docker. Then load-test it and watch where it breaks.
2. Break it on purpose. Kill the cache, slow down the database, cut the network, and see whether your timeouts, retries and fallbacks work.
3. Add observability. Metrics, traces and one SLO. Write a small postmortem for the failures you caused.
4. Read one engineering blog post or postmortem every week, and summarise it in five lines (post 65).
5. Read one classic in depth: Designing Data-Intensive Applications is the best next step for most readers.
6. Practise the framework on new problems. Design YouTube, Google Drive, a ride-hailing app, a payment system, a web crawler or search autocomplete.
7. Write about it. Explaining something is the fastest way to truly understand it.

Thank you for reading this series, whether you read every post or went straight to the topics you needed. System design is not about memorising architectures. It is about asking the right questions, understanding the trade-offs, and learning from how real systems succeed and fail.

Keep building, keep measuring, and keep learning. 🚀