Over-Engineering for Traffic You Do Not Have

Over-engineering is designing for a scale the requirements do not state. It looks like insurance against future growth, and it is a running cost: every extra part has to be built, deployed, watched and understood, every day, whether the growth arrives or not.

The symptom. An internal tool for 300 employees takes six months to ship. When it does, a simple change touches four services, a message broker that passes events between them, and a database split across several machines. Nobody on the team can hold the whole design in their head, and the tool serves about 2,000 requests a day, which one small server handles without noticing.

The trigger. Someone asks "what if it grows a hundred times?" and nobody answers with the requirement. Designs copied from large companies make it worse: a system built for millions of users solves problems a 300-user tool will never have.

The mechanism. Each part you add brings its own ways to fail. Splitting a database across machines, called sharding, means every query must find the right machine, and a query across all of them becomes slow and complicated. Running in three regions means keeping three copies of the data in agreement. These are good answers to real pressure; without the pressure they are only failure modes.

The cost. Months of building before anyone uses the product, a larger bill every month, slower changes for the life of the system, and more ways for it to break at three in the morning. The growth it was built for may never come, and if it does, the design may need to change in a direction nobody guessed.

The remedy. Design for the scale the requirements state, plus a sensible margin, and write down the point where the design would need to change. Check every part against the question "which requirement needs this?". A part with no answer is a cost with no return.