6 Architecture Mistakes You Only Find Under Load

The Problem with Architecture Reviews

Design reviews catch a lot. An experienced architect will spot a missing retry policy, question why two services share a database, or flag a component placed in the wrong network zone. Reviews are valuable.

But reviews have a structural limitation: they evaluate a system at rest. Architecture mistakes that only manifest under load — under real traffic, concurrent connections, timed-out dependencies, and cascading pressure — are nearly invisible in a review.

These six mistakes appear in diagrams as normal, well-structured systems. They appear in production as outages.

Mistake 1: Missing Dead Letter Queue

What it looks like in a diagram

Service A sends messages to Service B. The arrow connects them. The diagram is clean. Nothing looks wrong.

What happens under simulation

Service B goes down — a deployment, a timeout, a dependency failure. Service A keeps sending. Messages hit a closed destination and disappear. No error is surfaced to the user. No retry is attempted. The data is gone.

A dead letter queue (DLQ) captures messages that cannot be delivered, preserves them for inspection, and allows reprocessing after the downstream service recovers. Without it, a failure in any downstream service causes silent data loss — the most dangerous category of failure, because no alert fires and no dashboard turns red.

The fix is structural: every async message flow needs a DLQ on the receiving end. Simulation makes the absence of this structure immediately visible when you inject a downstream failure.

Mistake 2: Database as the Bottleneck

What it looks like in a diagram

Ten microservices, each with a line connecting to a shared database. The architecture is clear and centralized. The database node looks like any other.

What happens under simulation

At 3x baseline traffic, each of those ten services is spawning connections aggressively. A typical managed database allows 50–100 concurrent connections. At 3x traffic, ten services competing for 100 connections means each service is fighting for 10 slots. Connection pool exhaustion begins. Requests queue. Latency climbs. Services begin returning errors.

The database was never the bottleneck at baseline. At 3x, it is the only bottleneck, and it takes down all ten services simultaneously.

The fix requires read replicas, connection pooling middleware, or caching layers in front of the database — structural changes that must be made before load arrives, not after.

Mistake 3: No Circuit Breaker

What it looks like in a diagram

Service A calls Service B. Service B calls an external payment provider. Three nodes, two connections. Standard architecture.

What happens under simulation

The payment provider slows to 8-second response times. Service B is now blocking on every call, waiting for a response that takes 8 seconds instead of 200ms. Service B's thread pool fills. Service A, waiting for Service B, starts queuing. Service A's thread pool fills. New requests to Service A begin timing out. The user-facing tier fails — because a payment provider three hops away is slow.

A circuit breaker sits between Service B and the payment provider. When the provider's latency or error rate exceeds a threshold, the circuit opens: calls return a fast failure instead of a slow one. Service B recovers. The cascade stops.

Diagrams show connections. They do not show what happens when connections become slow. Simulation does.

Mistake 4: WAF After the API Gateway

What it looks like in a diagram

Two boxes: API Gateway and WAF. An arrow connects them. If you read the labels carefully, you can determine which is upstream — but at a glance, the diagram is ambiguous.

What happens under simulation

Traffic enters through the API Gateway first. The gateway parses the request, routes it, and processes it — before the WAF has seen it. Malformed inputs, injection payloads, and oversized requests reach the gateway's processing logic before any security filtering occurs.

The WAF must sit upstream of all traffic entry points — before the gateway, not after it. Requests hit the WAF first, are filtered, and only clean traffic reaches the gateway. The correct position is not a configuration detail. It is a structural requirement. Getting it wrong means the security layer is decorative rather than functional.

Simulation injects security scenarios — prompt injection, oversized payloads, malformed requests — and scores whether the architecture blocks them before or after they reach the processing tier.

Mistake 5: Agents Without Compute Containment

What it looks like in a diagram

LLM agents appear as labeled nodes. They are connected to other services. The diagram shows an AI-powered pipeline.

What happens under simulation

Agents without compute containment — without being wrapped inside a Kubernetes cluster, ECS task, or equivalent orchestrator — have no resource ceiling. An agent that experiences runaway token consumption, an infinite loop in a tool call chain, or a prompt that triggers excessive computation will consume unbounded resources. It will not be killed. It will not be restarted. It will not be isolated from other services.

Compute containment (K8s, ECS, Cloud Run) provides resource limits, restart policies, health checks, and isolation boundaries. Without containment, agents are a reliability and cost risk that does not appear in any diagram.

Simulation flags agents placed outside containment boundaries as a structural violation. The failure mode is visible in the scoring results before the agent ever runs in production.

Mistake 6: Monitoring as an Afterthought

What it looks like in a diagram

Often, it does not appear in the diagram at all. Observability infrastructure — metrics collection, log aggregation, tracing, alerting — is frequently omitted from architecture diagrams because it feels like operational overhead rather than architecture.

What happens under simulation

When a failure is injected — a database crash, a queue overflow, a cascading timeout — the simulation measures whether the architecture can detect it. Without observability components in the architecture, the failure is undetectable by the system. No alert fires. No metric spikes. No log entry captures the root cause.

The first outage in a system without observability is always followed by a long, expensive debugging session. The second outage in a well-instrumented system is solved in minutes.

Monitoring is not operational polish. It is a structural component. It belongs in the architecture diagram and in the simulation before the first deployment.

From Anti-Pattern to Production-Ready

Each of these six mistakes shares a common characteristic: they are undetectable in a design review and immediately visible under simulation. The diagram says the system is sound. The simulation shows where it breaks.

Catching these mistakes before deployment is not a matter of reviewing more carefully. It is a matter of putting the system under the conditions that expose the flaws — and doing that before production does it for you.

Start simulating at praxirun.com — free, no signup required.