The Three-Word Question That Changed Our Architecture

The Three-Word Question That Changed Our Architecture

Sarah Chen had been a Staff Engineer at a rapidly scaling fintech company for eight months when she attended what she thought would be a routine architecture review. The team was excited to present their solution for handling international payments - a complex distributed system spanning seven microservices with sophisticated event choreography.

Thirty slides in, Sarah asked three words that changed everything: “But actually, why?”

The Elaborate Solution

The team had spent three months designing what they proudly called “a highly scalable, event-driven, distributed architecture” for processing international payments. Here’s what they built:

Each service communicated via Kafka events. They had implemented saga patterns for distributed transactions, circuit breakers for resilience, and a sophisticated dead-letter queue system for handling failures.

The architecture diagrams were beautiful. The technology choices were modern. The engineering team was proud.

But Sarah asked: “But actually, why?”

Unpacking the Question

The team initially thought she didn’t understand. They began re-explaining the services.

“No,” Sarah interrupted gently. “I understand what you’ve built. I’m asking why you’ve built it this way. What problem does this architecture solve that a simpler approach doesn’t?”

The room went quiet.

Sarah continued: “Let me be more specific. Why seven services instead of one or two? Why events instead of direct calls? Why distributed transactions instead of local ones? For each architectural choice, what specific business or technical constraint forced that decision?”

This wasn’t skepticism for its own sake. Sarah had learned something crucial in her transition from Senior to Staff: the most important architectural skill isn’t knowing complex patterns - it’s knowing when NOT to use them.

The Discovery Process

What followed was a two-hour discussion that revealed several truths:

The Real Requirements:

The Actual Constraints:

What Drove the Complexity:

None of these were wrong motivations. But they weren’t architectural requirements.

The Staff Engineer Intervention

Sarah shared a principle she’d learned the hard way: “Every architectural decision has a cost. Microservices, events, distributed transactions - they’re all expensive. They cost development time, operational complexity, debugging difficulty, and cognitive load. You only pay those costs when the benefits clearly outweigh them.”

She walked through a series of questions:

Scalability: “At 500 transactions per day, a single Postgres database could handle literally a million times your load. Why distribute?”

Resilience: “Your fraud detection taking 30 seconds longer matters less than the system being down because of a Kafka partition rebalance you don’t understand yet. Which failure mode is worse?”

Team Velocity: “With four engineers, how much time will you spend on Kubernetes, service mesh, and distributed tracing versus building the actual payment features customers need?”

Compliance: “The audit trail is critical. Is it easier to guarantee correctness with seven services coordinating over eventually consistent events, or one database with ACID transactions?”

The Alternative Architecture

Sarah proposed a dramatically simpler approach:

One monolithic service with clear internal module boundaries:

The trade-offs:

The critical insight: “You can always split a monolith into services later when you have real data about bottlenecks. You can’t easily merge services back into a monolith when you realize you don’t need the complexity.”

The Pushback

The team had concerns:

“Won’t we regret this later?” Sarah: “Maybe. But you’ll definitely regret missing your launch deadline. And you’ll regret spending six months debugging distributed race conditions for 50 transactions a day.”

“Isn’t this architecture ’legacy’ from day one?” Sarah: “Legacy means it works reliably but is hard to change. This architecture will work reliably and be trivial to change because it’s simple. That’s the opposite of legacy.”

“What will we tell candidates? They want to work on modern architecture.” Sarah: “Tell them they’ll work on solving real business problems efficiently, not fighting self-imposed technical complexity. Great engineers appreciate that.”

The Outcome

The team rebuilt with the simpler architecture in three weeks. They launched on time. Here’s what happened over the next year:

Six Months In:

One Year In:

The Real Win:

The Lesson: Strategic Simplicity

Sarah’s three-word question taught the team a crucial lesson about technical leadership: the best architecture is the simplest one that solves the actual problem.

This isn’t about avoiding complexity forever - it’s about deferring it until you have real data proving you need it. Staff Engineers understand that:

Complexity is expensive: Every abstraction layer, service boundary, and distributed protocol costs development time, operational overhead, and cognitive load.

Requirements evolve: You’ll be wrong about what you need to scale. Build for today’s constraints with tomorrow’s flexibility, not next year’s hypothetical scale.

Reversibility matters: Prefer decisions you can reverse. Going from simple to complex is straightforward. Going from complex to simple is nearly impossible.

Team capacity is finite: A four-person team maintaining seven services means nobody has time to build features. Technical architecture should multiply team effectiveness, not divide it.

Questions to Ask

Sarah now uses these questions in every architecture review:

  1. “What’s the simplest solution that could work?”
  2. “What specific constraint forces more complexity?”
  3. “Can we defer this decision until we have more data?”
  4. “If this architecture fails, will it fail because it’s too simple or too complex?”
  5. “Would you rather debug this at 3am or something simpler?”

The irony isn’t lost on her: the most sophisticated architectural skill she developed as a Staff Engineer was knowing when to advocate for the least sophisticated solution.

The Three-Word Question

“But actually, why?”

Three words that force you to articulate the real requirements, not the assumed ones. Three words that distinguish between what’s technically impressive and what’s actually necessary. Three words that can save months of development time and prevent years of operational complexity.

The next time you’re reviewing an architecture - whether it’s yours or someone else’s - try asking it. You might be surprised what you discover.

Because sometimes the most advanced technical thinking is recognizing that you don’t need advanced technical solutions yet.

../