One team struggled for hours with a simple API change that required coordinating five different services. They thought they had microservices, but they'd built a distributed monolith: the worst of both worlds.
A CTO friend told me he regrets "staying with the monolith too long." A single slow database query took down the entire application. 80 people waited three days for a simple API change.
Another team spent five hours adding neighborhood filtering to an admin panel. Five hours. For a button that displays existing data.
Three stories, one lesson: good software architecture doesn't start with the database schema. It starts with understanding the business.
"Architecture Is the Database Schema"
Many people (primarily developers) think software product architecture is mainly about the database schema. That's understandable. It comes from where developers start: writing code, defining tables, connecting them together.
But that's the end of the process, not the beginning.
Designing a product is really an act of translation: business requirements → user workflows → architecture → code → schema. The schema is an output, not the starting point.
That's why the right questions to ask before any architecture decision are:
- How many users, concurrently? This determines whether you need horizontal scale from day one.
- What role are they in? End user, admin, automated agent: each has entirely different usage patterns.
- What response time is acceptable? 200ms for a public page is different from 5 seconds for an internal report.
- How do you protect privacy? This requirement shapes where data lives and how it's accessed.
Architecture derived from the answers to these questions holds up under growth pressure. Architecture that starts from "what's trending right now" doesn't.
Microservices as Solution and Microservices as Problem
The microservices debate has become one of the most toxic in software engineering. Some defend them unconditionally; others reject them on principle.
Both are wrong.
Microservices aren't about elegance or trends. They're about team independence.
The CTO's monolith story illustrates this: 80 people, fast delivery, everything working, until the breaking point arrived. One slow query took everything down. Features were blocked by an unrelated bug. The mobile team waited three days for a simple API change. "We thought it was simpler, but it turned out to be the bottleneck."
On the other side, the team with five coordinating services didn't solve the bottleneck problem. They distributed it.
Real microservices let each team deploy independently, fail independently, and scale independently. If a change to one service still requires coordinating with four other teams, you have a distributed monolith, not microservices.
Rico Fritzsche puts it well: the problem isn't a lack of tools: it's a fundamental misunderstanding of what real modularity means.
The Admin Panel as an Architecture Test
Five hours to add neighborhood filtering. Two hours frontend, one hour backend, two hours QA to check it didn't break pagination. For a button displaying existing data.
Developers hate building these interfaces. Product managers hate maintaining them. Support teams hate using them.
One engineering leader did something that sounds radical: replaced the entire admin panel with a React interface backed by Text-to-SQL. The result? Development velocity tripled overnight. The team defines the schema once, and support people ask in plain language: "Show me the five users with the highest LTV who haven't purchased in the last month."
The deeper point: five hours to add a neighborhood filter isn't a development problem: it's an architecture problem. When admin interfaces are expensive to change, it's a signal they weren't designed as part of the whole picture.
Takeaways
Good architecture isn't the kind that looks clean on a diagram: it's the kind that lets a team move fast, fail safely, and grow without rebuilding every few years.
Three lessons from these stories:
- Start from the business, not the technology
- Verify team independence before calling something microservices
- Expensive admin interfaces are an architectural symptom, not an inevitable cost