An architecture review reveals a proposed system requiring service discovery, several databases, distributed locks, a message broker, CQRS, event sourcing, a container orchestrator and a service mesh - for a workload expected to have a few thousand users. What would you simplify and how would you justify it?

What the simplified design looks like

One application, one relational database, one managed queue, one managed deployment platform. That handles a few thousand users comfortably, and it handles a few hundred thousand for most workloads.

Specifically removed and why:

• Service discovery — with one deployable there is nothing to discover.
• Several databases — one Postgres handles documents, full-text search and time-series adequately, and one well-operated store beats four specialised ones for a small team, because operational simplicity is worth more than per-workload optimisation.
• Distributed locks — with one process and a database, transactions and unique constraints provide the exclusivity. And most cases proposed for a lock should be made idempotent instead: coordination is a cost, idempotency is a property.
• Message broker — a database-backed queue is sufficient at this volume, and it removes an entire system from the operational surface.
• CQRS and event sourcing — neither has a stated requirement. Both are permanent costs applied to everything they touch.
• Container orchestrator and service mesh — machinery for operating many services, of which there is one.

How to justify it

Not by arguing against complexity in general, which loses to the response that the team is planning ahead. Justify it decision by decision:

• Ask for the requirement each component satisfies, stated as a number or a constraint. Most will not have one, and the absence is the argument.
• Name what each costs: a system to operate, patch, monitor, back up, fail over and be paged for, plus the expertise that must exist at 3am.
• Point at the reversibility. Adding a broker later, when a measured need exists, is a week. Adding event sourcing later is expensive, which is precisely why it should not be adopted speculatively — and removing it is worse.
• Offer the trigger. "We will add a broker when queue depth in the database exceeds X" converts a refusal into a plan and removes the argument's emotional content.

The one thing to insist on despite the simplification

The data model, the tenancy key and the identity scheme. These are the decisions that are genuinely expensive to reverse, and simplifying elsewhere buys the time to get them right.

Simplicity is not the absence of design; it is design concentrated where reversal is costly.