The First Version of My Product Was Too Complicated
I kept adding architecture because I was solving problems that did not exist yet. Simplifying the system made it easier to ship and easier to change.
I have made this mistake more than once.
I get interested in the architecture before the product has earned it.
A new service. A queue. A cache. A separate worker. Another database. A new abstraction that is supposed to save time six months from now.
Then I look at the product and see there are not enough users to justify any of it.
Future problems are easier to design for
It is easy to design for 10 million users.
I know roughly what that architecture looks like. I can draw boxes. I can talk about scaling. I can pick technologies. I can feel busy.
The harder question is: what problem do we actually have today?
That question is less fun. It is more useful.
I ask what breaks first
Before I add another component, I try to name the actual constraint.
Is the database slow? Are background jobs unreliable? Are API requests timing out? Are deployments risky? Are users waiting too long?
If the answer is no, I probably do not need another system yet.
A scaling problem I might have later is not automatically an engineering problem today.
Simple is not the same as careless
A simple architecture can still have:
- clear boundaries
- good error handling
- idempotent operations
- logs
- tests
- sensible database indexes
- backups
- monitoring
I can do all of that without splitting a small product into a long list of services.
Extra parts cost time later
Every new component creates work.
Someone has to understand it. Someone has to deploy it. Someone has to monitor it. Someone has to debug it at 2 AM.
That cost is easy to ignore in an architecture discussion because it does not show up in the diagram. It is still real.
Let the architecture follow the product
I now prefer an architecture that can change, not one that tries to predict the next few years.
I start with the simplest thing that gives clean boundaries. I measure where it hurts. Then I split that part.
Not everything needs to be a microservice. Not every job needs a queue. Not every read needs Redis. Not every AI task needs an agent.
Sometimes a well-structured application is enough.
The architecture I want is the one that lets me change the product without a large rewrite.