The Architecture Game

Three Questions That Stop Over-Engineering Before It Starts

It’s Thursday afternoon, and six engineers are standing around a whiteboard. Someone has just drawn a clean, simple architecture for the new order processing system. One service. A relational database. A well-defined API. It handles every requirement in the spec. A junior developer could trace the request flow in ten minutes.

Then the questions start. “What about international customers?” Reasonable. Someone draws a currency conversion module. “What if we need a second payment provider?” Another box. An adapter layer with a strategy pattern. “Shouldn’t this be event-driven?” Two more boxes. A message queue. A saga orchestrator.

Forty-five minutes later, the single-service architecture has become four microservices, an event bus, and a configuration system for scenarios nobody has actually requested.

Here is the part that should bother you: nobody in that room wanted this outcome. Every question was reasonable. Every addition was defensible. And the result is a system that will take three months to build instead of three weeks, that nobody will fully understand six months from now, and that will turn a 2 AM production incident into an archaeology expedition across four teams.

This is a game theory problem.

The Trap

Game theory studies what happens when multiple people make decisions that affect each other. That’s architecture. Your choice of abstraction affects my ability to debug. My choice of dependency affects your ability to deploy. Nobody controls the full outcome. Everybody’s move changes everybody else’s game.

The prisoner’s dilemma maps directly to design reviews. Replace “cooperate” with “build simple” and “defect” with “build comprehensive.” If both teams build simple, the system is clear and everyone benefits. If one team builds simple and the other over-engineers, the over-engineers look thorough while the simplifiers look lazy and short-sighted. In the next architecture review, the over-engineers get praised. The simplifiers get questioned. Both teams over-engineer. The collective result is a system nobody wanted, nobody can maintain, and nobody can debug at 2 AM.

The incentives behind this trap run deep. Architecture reviews are social events with real status stakes. When someone asks “What about customers in Germany?” the path of least resistance is to answer “we handle that” rather than “we’ll handle that when we need to.” Saying “we handle that” earns social capital. It signals competence. Saying “we’ll handle that later” sounds like a dodge. Nobody wants to be the architect who forgot about edge case X. And the career game makes it worse: nobody puts “built a monolith that worked perfectly for three years” on their LinkedIn profile. They put “designed a distributed event-driven architecture with twelve microservices.” The career game rewards complexity. The project game punishes it. The career game usually wins.

This is a Nash Equilibrium: a state where no individual player benefits from changing their strategy alone, though everyone would benefit from changing together. Traffic jams are Nash Equilibria. Everyone would be better off if half the drivers took a different route, but no individual driver benefits from switching. Everyone sits in traffic. Stable, but miserable.

Your forty-seven-microservice architecture is the same kind of stuck. Every team knows it’s too complex. No single team can simplify their piece without breaking contracts with the other forty-six. Everyone stays put.

This is why “just simplify” fails as advice. It’s like telling a prisoner’s dilemma player “just cooperate.” It ignores the incentive structure entirely. You do not fix a broken game by asking the players to lose on purpose. You fix the game.

Three Questions That Fix the Game

Mechanism design is the branch of game theory that asks: how do you design the rules of a game so that the winning strategy produces the outcome you want? Coding standards and best-practices wikis fail because they ask people to play against their own incentives. People do not play against their own incentives for long, no matter how many all-hands meetings you hold about technical excellence. Instead of hoping engineers resist bad incentives through willpower, you restructure the incentives so the simple choice becomes the rational choice.

Three questions do this. Each one can be thrown into a spiraling design review and change the direction of the conversation in seconds.

Question 1: “Could a tired engineer debug this at 2 AM?”

This is the 2 AM Test. It replaces elegance and comprehensiveness as the measure of architectural quality with a single operational standard: survival under stress.

When this question becomes the standard in your design reviews, the social mechanics flip. The engineer who proposes the simpler solution is no longer “lazy.” They’re the person who won’t get the team paged at 2 AM. The engineer who adds three layers of indirection is no longer “thorough.” They’re the person creating a system that can’t be debugged under pressure. Simplicity earns status. Complexity requires justification. The Nash Equilibrium moves.

Question 2: “Do we have a single user who needs this today?”

This is the Half-Rule: build half of what you think you need. The question separates real requirements from speculative ones in seconds.

“What if we need a second payment provider?” “Do we have a single user who needs this today?” No. Then it’s not on the board. The question doesn’t dismiss the concern. It timestamps it. The concern becomes real when a real user makes it real. Before that, it’s fiction wearing a costume labeled “foresight.”

Watch the room when this question lands. The engineer who proposed the addition can’t argue against it without admitting they’re building for an imaginary customer. The person asking the question becomes the rigorous one. The person proposing the speculative feature has to justify spending the team’s time on something nobody has asked for.

Question 3: “What percentage of our users will ever touch this?”

This is Primary Path First: design for the 95% case. The question forces a number into a conversation that usually runs on vibes.

“What about international customers?” “What percentage of our users will ever touch this?” Three percent, eventually. Then, international payment doesn’t get to shape the architecture. It lives behind a seam. The primary path handles domestic checkout in twelve lines of code that read like a story: receive payment, validate amount, check fraud policy, charge card, record transaction, send receipt. Currency conversion gets built when it matters, contained where it belongs.

Without this question, the engineer who surfaces the most exotic edge case wins the most status. With it, the engineer who keeps the primary path cleanest wins. The competition shifts from “who found the scariest scenario” to “who made the common case simplest.” That is a game worth winning.

Back to the Whiteboard

Same Thursday afternoon. Six engineers. Same questions. But now the team has three shared responses.

“What about international customers?” “What percentage of our users will ever touch this?” Five percent. It lives behind a seam.

“What if we need a second payment provider?” “Do we have a single user who needs one today?” No. Build for the provider we have.

“Shouldn’t we make this event-driven?” “Could a tired engineer trace a failed order through that system at 2 AM?” If the honest answer is “maybe, with the right tooling,” then the honest answer is no.

Forty-five minutes later, the whiteboard still has one service. The edge cases have been acknowledged, documented, and given future addresses. The system can be built in three weeks. The on-call engineer can debug it at 2 AM. And the team’s complexity budget is intact, ready to be spent on problems that actually materialize instead of problems someone imagined during a Thursday afternoon whiteboard session.

The game has not changed. The questions are the same. The players are the same. The conference talks still celebrate complexity. The résumé still rewards sophistication. The fear of looking incomplete still lurks in every design review.

What changed is the rules.

You do not fix over-engineering by asking engineers to be less thorough. You fix it by changing the game so that thoroughness and simplicity point in the same direction.

Stop playing the wrong game. Rewrite the rules.

Keep it simple, keep it clean, and don’t let the bloat win.