Good Architecture Means Cutting Components, Not Adding More

Experienced developers possess the skill of recognizing which parts of a system can be omitted temporarily, thereby lowering overall complexity.

In many projects, once a system matures, there is a tendency to keep adding components—e.g., introducing Redis when MySQL feels slow, adding a message queue for asynchronous processing, or deploying a rule engine in anticipation of many future rules. The author observes that each added component is mistakenly seen as an architectural improvement, while it actually inflates system complexity.

For instance, if a business’s traffic is modest and MySQL can handle the load, inserting a Redis cache adds the need to decide when the cache should be refreshed, whether to delete the cache before updating the database, and to write additional code to keep cache and database consistent.

Another example is a system that originally has a single service but developers move all asynchronous tasks to a message queue. This introduces an entire broker infrastructure, extra operations, monitoring, and new failure modes such as duplicate messages, message loss, backlog buildup, and retry handling. In many cases, a simple thread pool or Spring’s built‑in event‑publish/subscribe mechanism is sufficient for asynchronous execution.

The author enforces a strict rule: new components may only be introduced when no existing technical solution can address the problem, because each dependency raises the system’s complexity.

Software architecture, at its core, is about managing complexity. Adding a component is easy; removing one requires experience and judgment. A hallmark of good architecture is a trend toward fewer dependencies and a progressively simpler system.