10 system design rules I always come back to
SubscribeSign in
10 system design rules I always come back to<br>These took years to learn. 5 minutes to read
Adlet Balzhanov<br>Jun 24, 2026
Share
I've been compiling these system design interview rules for years. Friends found them useful. Figured it was time to share them properly.<br>Rule 1 – System design is all tradeoffs. There’s no perfect choice, just better or worse ones.<br>Rule 2 – Good design starts with the right questions:<br>Read-heavy system or write-heavy?
What guarantees do we actually need? (e.g. exactly-once execution within 24h?)
How fresh does the data need to be? Is replication lag acceptable?
Steady traffic or bursty?
What’s the recovery expectation when things go wrong?
Do we need to keep the data forever?
Rule 3 – Environment matters. Before your interview, ask your recruiter which whiteboard tool they are using and spend time in it beforehand. Fumbling with the UI is unnecessary cognitive load on top of an already hard problem.<br>Rule 4 – Before listing your non-functional requirements, ask about scale. It’ll shape everything.<br>Rule 5 – When thinking about storage, always walk through the spectrum where to store the data: server in-memory → Redis → persistent DB → blob storage (S3). Run the numbers based on your non-functional requirements list.<br>Rule 6 – Durability isn’t just “3 replicas.” You also need to verify each copy is actually correct (e.g. checksums with SHA-256).<br>Rule 7 – Start simple. OpenAI scaled ChatGPT to 800M monthly users on Postgres: 1 primary, 50 read replicas. The moment you cross a network boundary, latency gets real, partial failures become possible, retries get dangerous.<br>Rule 8 – Don’t ignore the client side. Batching, chunking, compression. This stuff meaningfully cuts backend load and improves scalability.<br>Rule 9 – Some processes can't be atomic. Payments are the clearest example. Authorization, capture, settlement, refund, dispute. Each step can fail independently and may need retries or compensation. That’s the Saga pattern and why tools like Temporal exist.<br>Rule 10 – Read path: optimize for speed. Write path: optimize for correctness.<br>If this was useful, send it to someone prepping for a system design interview. Drop your own rules in the comments. Curious what I’m missing.<br>Thanks for reading,<br>Adlet Balzhanov<br>📌 FREE to join: weekly newsletter, helping 3,800+ Big Tech engineers level up fast. Read by engineers from Google, Meta, Amazon, Microsoft and more
Subscribe
Connect with me on LinkedIn, just use the button below. I read every message. Cheers!<br>My LinkedIn
Share
Discussion about this post<br>CommentsRestacks
TopLatestDiscussions
No posts
Ready for more?
Subscribe
© 2026 Adlet Balzhanov · Privacy ∙ Terms ∙ Collection notice<br>Start your SubstackGet the app
Substack is the home for great culture
This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts