This blog is a study log for a technical software architecture interview. It is written in a fixed order, and the posts build on each other. If you read them in the sequence below, each design question will make sense the first time, because the concept it depends on has already been explained.

How Every Post Is Built

Each question post has the same shape, so you can skim them the same way:

1. The question, phrased the way an interviewer asks it, plus the common variants
2. What they are really asking, meaning the competency being probed
3. The gotchas, where candidates go wrong and why
4. How to answer, a structured walkthrough with diagrams and trade-off tables
5. Follow-up questions to expect
6. Key takeaways

Subject posts drop the first section and explain a concept the design questions depend on. Every gotcha from every post is collected on the Gotchas page, and every term is defined on the Glossary page.

The Reading Order

Foundations, in sequence

1. How to Run the First Five Minutes of a System Design Interview. The opening that every later design uses: restate, scope, name the non-functional requirements, estimate three numbers, find the hard part, agree on a plan.
2. Back-of-Envelope Numbers Every Architect Should Have Memorized. The reference page for the “estimate three numbers” step: time conversions, the latency ladder, throughput per node, sizes, costs, availability math.
3. What Consistency Actually Means. The ladder from linearizable to eventual, the anomaly each level prevents, and the mechanism that enforces it. This is the vocabulary for “the display is eventual; the decision is linearizable.”
4. Transaction Isolation Levels. The other axis: what concurrent transactions on one copy can do to each other, what your database actually defaults to, and the toolbox for preventing lost updates and write skew without serializable.
5. Idempotency Keys, Properly. How retries are made safe: who generates the key, where the record lives, how the check is made atomic, what to return on replay. Every design with a payment or a queue depends on this.
6. Sagas and the Outbox Pattern. How a process spans services without a distributed transaction. The outbox fixes the dual-write bug; the saga sequences local transactions with compensations.
7. Design a Ticket Booking System. The capstone. A full design that uses all six foundations and points at each one where it applies.

Design questions

Each of these is a complete answer to a classic question. Read them after the foundations, in any order.

Post	Shape of the system	The hard part
Design a URL Shortener	Read-heavy lookup	ID generation and the 301 vs. 302 decision
Design a Rate Limiter	Coordination on a shared counter	Atomicity in the store, and what happens when the store is down
Design a Distributed Job Scheduler	Coordination with time	At-least-once delivery, leases, and misfire policy
Design a Ticket Booking System	Contended writes with a peak	The hold, the waiting room, and the payment saga
Monolith or Microservices?	An organizational decision disguised as a technical one	Naming the trade-offs and what would change your mind

Leadership and behavioral

• “Tell Me About a Time an Architecture Decision Went Wrong”. How to choose the story, tell it in six beats, and handle the follow-ups that catch people blaming the team.
• “How Do You Disagree With a Senior Engineer?”. The companion question: a playbook for pushing back with evidence, calibrating to reversibility, and committing once the decision is made.

Coding screens

• Ten Coding Interview Questions in Kotlin. The ten patterns a senior coding round draws from, each with an idiomatic Kotlin solution, the mistake interviewers listen for, and the Kotlin-specific traps that give away occasional users.
• Ten More Coding Interview Questions in Kotlin. Part two: monotonic stacks, two pointers, bounded tree recursion, topological sort, quickselect, backtracking, and the trie, with a second set of Kotlin traps.
• Concurrency in Kotlin. The coroutine questions senior loops ask: structured concurrency, cooperative cancellation, dispatchers, exception propagation, shared mutable state, and Flow versus Channel, ending with the fetch-with-a-budget question that combines them all.
• “Find the Bug in This Function”. The debugging round: ten functions with one planted bug each, drawn from the gotchas in the three posts above, with the failing input, the class of bug, the minimal fix, and the method that finds them in under a minute.

Reference Pages

• Gotchas: every gotcha from every post, grouped by theme, as a pre-interview checklist.
• Quiz: the same gotchas with the explanation hidden until you click, with shuffle and a per-browser “I know this” mark so you can drill the ones you do not.
• Glossary: one line per term, linked to the post that explains it.
• Categories and Tags for browsing by topic.

What Is Coming

More design questions written at the ticket-booking depth (payments, news feed, distributed cache, chat, workflow orchestration), more subject posts (versioning and conditional writes, consensus, retries and circuit breakers, sharding, multi-region), and more of the leadership questions that come with the role. The Archives page lists everything by date.