Distributed systems have a time problem that isn't obvious until it bites you. Two events happened — one on Node A, one on Node B. Which came first? That question has two different answers depending on what you mean by "first": physical time order, or causal order.
System Overview Observer Analysis Tweet Author (Initiator) Type: Initiator Time: How long from posting until they know the tweet exists? Then, distribution latency. How long until followers can see it? Wrongness tolerance: Cannot tolerate lost tweets—posted but never persisted. Cannot tolerate ambiguity—did it post or not? Can tolerate
Let's now put our framework for System Design into practise. I'll try and be as comprehensive for the sake of clarity. System Overview Observers Rider Type: Initiator Time: Acknowledgment latency. How long from requesting until knowing a driver is assigned? Wrongness tolerance: Cannot tolerate ambiguity—must
Pressure: Why Systems Break Now Pressure is not traffic. Not queries per second. Not concurrency or peak load. Those are measurements. Pressure is the rate at which expectations are created relative to the system's ability to resolve or absorb wrongness. A low-traffic system can be under extreme pressure
Wrongness: What Each Observer Tolerates Wrongness is not bugs or errors or incorrect data. Those are manifestations. Wrongness is the distance between what an observer expected and what they encountered—a distance that exceeds what they can tolerate. Every observer has a tolerance band. Within the band, deviations are acceptable.
Time: The Debt You Redistribute Time is the gap between when an observer forms an expectation and when they evaluate whether reality matched it. Each observer tolerates a different gap. This is why temporal conflicts are inevitable. Initiators live in immediate time. An initiator takes an action and starts waiting.
All system design problems reduce to managing how time, wrongness, and pressure are perceived by their observers. An observer is anything that forms expectations about the system and reacts when those expectations are violated. It expects something to happen. It changes behavior when that expectation isn't met. If
The better you get at pattern-matching system design answers, the worse you get at actually designing systems. This sounds wrong. It's not. You've witnessed the moment it falls apart. Perhaps you've lived it yourself. The interviewer says "Design a rate limiter." The
Everything Traces Back to Bugs Strip away the methodologies, the management frameworks, the process improvements, and software engineering has exactly two categories of problems: 1. Bugs - the reliability and testing problem 2. Dealing with the unpredictability of bugs - the management and scheduling problem Every other concern in software
The Pattern Recognition Problem There's something curious about the most popular programming books. Clean Code. The Pragmatic Programmer. Refactoring. Design Patterns. All are written by people who built large, complex systems. All contain reasonable, even excellent advice. And yet, if you try to apply them to a large
The Feedback We Think We're Getting Software development has feedback mechanisms built into its standard practice. Code reviews before merging. Test suites that must pass. API contracts that must be satisfied. These are supposed to catch problems, enforce quality, and help programmers improve. But here's the
The curriculum was invisible, but you learned it anyway. The Invisible Curriculum There's a peculiar gap in software engineering that we rarely discuss openly: the vast distance between what universities teach and what professional programmers need to know. I don't mean the usual complaints about outdated