Scalability
scalability
System Design
Horizontal vs Vertical Scaling
When traffic grows, you have two choices: make the box bigger (vertical) or add more boxes (horizontal). This lesson lays out the cost, complexity, and ceiling of each approach, why stateless services scale horizontally with almost no thought, why stateful services require sharding or replication, and how real teams pick a default. By the end you can answer 'how would you scale this?' with a defensible answer instead of an instinct.
Auto-Scaling, Elasticity & Capacity Planning
Auto-scaling lets your fleet grow when traffic surges and shrink when it ebbs, so you pay for the load you actually have. This lesson covers reactive metric-based scaling, predictive (schedule-based) scaling, and the gotchas that turn auto-scaling into auto-outage: warm-up time, scale-down storms, downstream throttling, and cost runaway. We also walk through capacity planning: how to estimate the fleet size you need from QPS, latency targets, and headroom, before relying on the scaler to fix mistakes at 3 a.m. By the end you can configure an auto-scaling policy with confidence and explain to an interviewer why simply 'putting it on auto-scale' is not the actual answer.
Behavioral Interviews
Navigating Technical Trade-offs
Trade-off questions are the senior-engineering judgement probe. They test whether you can weigh competing technical priorities, articulate the criteria that drove your choice, own the path you took including its costs, and distinguish real trade-offs from false choices that better engineering would dissolve. This lesson defines trade-off literacy across the canonical axes (consistency vs availability, build vs buy, simplicity vs flexibility, speed vs safety, cost vs latency), walks through the explicit-criteria framework strong candidates use to make trade-offs visible, covers the technical-debt framing that scores best in interviews, and provides fully worked model STAR answers for the prompts you will hear most. After this lesson you will be able to take any consequential technical choice from your career and tell the story so the rubric reads judgement, calibration, and ownership simultaneously.
System Design Decision Stories
System design decision questions are the staff-and-above architecture probe. They test whether you can shape a design that compounds correctly over years, demonstrate second-order thinking about how decisions interact, balance forward-looking design with iterative delivery, and tell a story that operates at the right altitude for staff scale. This lesson defines what counts as a scale-shaping decision (architectural choices whose costs and benefits compound), walks through how to present design decisions in narrative form rather than whiteboard form, covers the second-order-thinking moves that distinguish staff stories from senior stories, addresses when to over-engineer versus when to ship-and-iterate, and provides fully worked model STAR answers for the prompts you will hear most. After this lesson you will be able to take any consequential architectural decision from your career and tell the story so the rubric reads design judgement, second-order thinking, and operating at staff altitude.
Community
Designing a Feed in 45 Minutes at a Mid-Size SaaS
A senior system design round at a mid-size B2B SaaS where the prompt was a generic activity feed but 45 minutes forced me to commit to a fan-out strategy in the first ten minutes.
SQL vs NoSQL: Stop Asking the Wrong Question
The choice that matters is not the data model. It is which guarantees you need on read and write. A decision table and the JSONB middle ground that retired half my Mongo use cases.
Connection Pooling, PgBouncer, and the Prisma Trap
What a connection pool actually does, why your Postgres falls over at 200 connections, where PgBouncer sits, and the prepared-statement bug that bites every Prisma team that adds it the wrong way.