Accidental vs Essential Complexity

Essential complexity is inherent in the problem: a global marketplace really does have currency, tax, fraud, regulation and time zones, and no architecture removes them. Accidental complexity is what your solution added: the message broker introduced for a workflow a database table would have served, the sixth deployment pipeline, the service boundary drawn along an org chart that has since been reorganised.

The distinction matters because the two respond to opposite treatments. Essential complexity should be isolated and named so it is handled in one place by people who understand it. Accidental complexity should be deleted.

Why it matters

Almost every "our architecture is too complex" conversation fails because nobody separates the two. Engineers defend essential complexity as if it were their design choice, and defend accidental complexity as if it were the domain's fault. Both defences block the conversation.

Implementation patterns

• The removal test. For each component, ask: if the business problem stayed identical but we rebuilt from scratch today, would this exist? No means accidental.
• Complexity budgets. A stated ceiling on the number of runtime dependencies, data stores or deployment units a team may own, forcing an explicit trade when something new is added.
• Domain isolation. Push essential complexity into a well-named module with tests that read like the regulation they encode. Tax logic sprawled across twelve services is essential complexity that has been converted into accidental complexity by bad placement.

Industry example

A team building an internal workflow for a few thousand users adopts Kubernetes, a service mesh, an event-streaming platform, CQRS with separate read models, and event sourcing, then finds that a two-field change requires touching four repositories and a schema registry, and that local development needs a machine nobody has.

None of that complexity came from the problem. The problem was a form, an approval chain and a report. Contrast that with the genuine essential complexity a platform like Twilio carries: delivery receipts that legitimately never arrive for some carriers, per-country regulatory sender identifiers, and per-provider throughput ceilings that differ by an order of magnitude. Those cannot be abstracted away without producing silent incorrectness — they can only be modelled explicitly and kept in one place.

The tell is what happens when you propose deletion. Proposing to delete the service mesh produces an argument about best practice. Proposing to delete per-country sender identifiers produces a regulator.

Failure scenarios

• Complexity laundering. Accidental complexity justified by a future requirement that never arrives — "we will need this when we scale".
• Essential complexity smeared. Domain rules duplicated across many services, so a single regulatory change becomes a multi-team programme.
• Resume-driven architecture. Technology chosen for its interest rather than the problem's shape, then defended on grounds that cannot be falsified.
• Simplification that deletes the wrong thing. A cleanup that removes an odd-looking special case which was in fact the only handling of a real-world edge condition.

Trade-offs

Removing accidental complexity costs migration effort now and buys lower change cost forever. But the judgement is genuinely hard at the margin: some accidental complexity is load-bearing scaffolding for growth you can already see, and deleting it is a real regression. The honest question is not "is this necessary?" but "what evidence would tell me it is necessary, and do I have it?"

Interview question

"An architecture review finds a proposed system needs service discovery, multiple databases, distributed locks, a message broker, CQRS, event sourcing and Kubernetes — for a workload expected to have a few thousand users. What do you cut, and how do you justify the simpler design to a team that has already committed to it publicly?"