The most important system design decision you make is rarely about technology — it is about consistency model. Strong consistency (every read reflects the latest write) limits horizontal scaling because nodes must coordinate. Eventual consistency (reads may be stale) enables massive scale but requires your application to handle divergence. Before choosing a database, a cache strategy, or a replication model, ask: "Can my users tolerate reading slightly stale data?" If yes, you have design freedom. If no, every component on the read path must enforce consistency — and that constraint propagates through your entire architecture.

The key mental model: memory → disk → network, each 100x slower. L1 cache (1ns) → RAM (100ns) → SSD (16μs) → HDD (4ms) → network same-DC (0.5ms) → cross-globe (150ms). If you remember nothing else: "in-memory is microseconds, disk is milliseconds, cross-continent is hundreds of milliseconds." This tells you instantly whether a design will meet latency requirements.

The #1 differentiator between mediocre and excellent candidates: trade-off articulation. A mediocre answer says "use Kafka." An excellent answer says "I'd use Kafka here because we need ordered delivery within a partition, at-least-once guarantees, and the ability to replay events if the consumer fails. The trade-off is operational complexity — if the team is small, an SQS queue would be simpler with acceptable ordering relaxation." Name the alternative, explain why you didn't choose it.