Simulation Model Library

After a deployment or Redis restart, a sudden burst of traffic hits the origin with a fully cold cache. Every request misses and simultaneously hammers the database. Unlike a gradual cache miss, a cold-start stampede compresses all miss load into a single second: the database sees its entire warm-state load in one instant, with no ramp-up time to absorb the flood.

Redis cache cluster + PostgreSQL primary + load-balanced application server pool

As DAU grows, application instances scale horizontally to handle throughput. Each instance maintains its own connection pool to PostgreSQL. Total database connections grow linearly with instance count: not with user load. When total connections across all instances exceeds PostgreSQL max_connections, new connections are refused and application requests fail with "too many clients" errors, regardless of per-instance utilization.

PostgreSQL primary (max_connections=200) + PgBouncer pooler + N application instances each with pool_size=10

In a CQRS architecture, the read-side projection processor falls behind the event stream. The query model serves stale state while the command model has already accepted and committed new writes. As projection lag grows, reads become increasingly inconsistent with writes: violating the eventual consistency promise and exposing users to stale, contradictory, or missing data.

Event store (PostgreSQL/EventStoreDB) + projection processor + read model (PostgreSQL read replica or denormalized store)

A multi-region deployment routes reads to the nearest regional replica. Under write surges or inter-region network degradation, the regional replica accumulates replication lag. Reads from the lagging region return state that contradicts recent writes: violating read-after-write consistency. If lag reaches the WAL retention boundary, the replica cannot resync incrementally and requires a full base backup across regions.

Primary region (us-east) + replica region (eu-west) + global read router + regional CDN

In a multi-region or multi-instance deployment, a write to the primary datastore fails to propagate cache invalidation to all cache nodes. Some cache instances continue serving stale data while others serve fresh data: users in different regions or on different application servers see contradictory state for the same entity. The inconsistency silently widens as TTL-based expiry is the only eventual recovery path.

Multi-region cache cluster (Redis Cluster or Memcached) + primary PostgreSQL + regional application servers

A mapping change, schema migration, or index rebuild forces Elasticsearch to reindex a large corpus of documents. The reindexing process competes with production indexing and search traffic for JVM heap, I/O, and thread pool resources. Merge pressure from new segments saturates I/O, query latency spikes, and if heap fills with segment metadata, the node faces GC pressure that can trigger a stop-the-world pause: pausing the entire shard for seconds.

Elasticsearch cluster (3 data nodes, 1 master) + indexing pipeline + search API

A large-scale event replay: triggered by a projection rebuild, a bug fix requiring reprocessing, or a new consumer catching up from offset zero: floods the event store and downstream systems with a burst of historical events. The replay storm saturates database write capacity, overloads downstream services not designed for burst replay, and surfaces non-idempotent handlers that produce duplicate side effects.

Event store (Kafka or EventStoreDB) + projection processor + downstream OLTP database + external API consumers

A slow consumer, processing spike, or deployment-induced rebalance causes consumer lag to accumulate on one or more topic partitions. As the backlog grows, it approaches the retention boundary. If the consumer group falls behind faster than it can recover, messages are lost at the retention boundary: a silent, unrecoverable data loss event.

Kafka cluster (3 brokers) + producer service + consumer group (3 instances)

In a shared-database multi-tenant deployment, a single tenant executes large analytical queries, bulk exports, or bulk operations that consume disproportionate database CPU, I/O, and connection resources. Other tenants on the same PostgreSQL instance experience latency degradation proportional to the noisy tenant's resource consumption, with no isolation boundary to contain the blast radius.

Single PostgreSQL instance serving N tenants via row-level tenant_id filter, no per-tenant resource limits

Sequential or low-cardinality partition keys concentrate writes on a single partition or shard, creating a hotspot. The hot partition absorbs disproportionate I/O, CPU, and memory pressure while other partitions sit idle. As load grows, the hotspot becomes a hard throughput ceiling for the entire table or topic.

Partitioned PostgreSQL table or Kafka topic with sequential key pattern

A write-heavy burst (batch imports, end-of-day reporting loads, or viral traffic) causes the WAL replication stream to fall behind. The replica accumulates lag, stale reads proliferate, and read-after-write consistency violations surface before the primary absorbs the burst and lag self-heals.

Primary PostgreSQL + 1 streaming replica serving read traffic

Sequential scan queries on a large table without appropriate indexes consume CPU and I/O proportionally to table size. At 1 million rows a missing index is invisible. At 10 million rows the same query causes user-visible latency. At 50 million rows it triggers database CPU saturation, connection pool exhaustion, and cascading failures across all users sharing the database: while the query plan has remained unchanged throughout.

PostgreSQL primary with growing OLTP table, no index on high-cardinality filter column

A slow consumer, consumer crash, or downstream service degradation causes messages to accumulate in a RabbitMQ queue. As the backlog grows, broker memory fills with queued messages, triggering the memory alarm. RabbitMQ blocks all producers : turning a consumer bottleneck into a full producer halt across every connected application.

RabbitMQ broker (3-node cluster) + producer services + consumer pool + downstream database

ORM misuse generates N+1 query patterns: fetching a list of 100 records triggers 100 individual lookup queries for associated records. Each individual query is fast in isolation, but under moderate concurrent load the pattern causes connection pool saturation, exponential latency growth, and database CPU exhaustion that is invisible from per-query metrics alone.

PostgreSQL primary + ORM application layer + connection pooler (PgBouncer)

A cache key (or key namespace) expires or is evicted simultaneously for many users. Thousands of requests hit the database to recompute the same value: a cache stampede. The database becomes overwhelmed, latency spikes, and the cache fills too slowly to absorb the flood, causing a self-reinforcing collapse loop.

Redis cache layer + PostgreSQL primary + application server pool

A downstream service: database, external API, or internal microservice: experiences elevated latency. Upstream services with aggressive retry logic treat slow responses as failures and immediately retry, amplifying the original request volume by 3-10×. The amplified load prevents the downstream service from recovering, turning a transient slowdown into a sustained outage sustained entirely by the retrying callers.

Microservice mesh: 3 upstream services each with retry-on-timeout logic targeting a single downstream service

A network partition between PostgreSQL primary and standby causes the standby to promote itself to primary after the failover timeout expires. Both nodes accept writes simultaneously: the classic split-brain condition. When the partition heals, the original primary reconnects to find a diverged WAL timeline. Conflicting writes from both nodes cannot be automatically reconciled. One node's writes must be discarded, and the decision about which writes to keep is a manual, irreversible data operation.

PostgreSQL primary + synchronous standby + Patroni/pgautofailover HA manager with 30-second failover timeout

A write-heavy table: audit logs, events, time-series metrics: grows unbounded without a retention or archiving policy. Dead tuples from high-churn UPDATE and DELETE operations accumulate faster than autovacuum can reclaim them. Table bloat causes sequential scans to read tens of millions of dead pages, the query planner degrades on stale statistics, and autovacuum becomes the dominant I/O consumer on the host.

PostgreSQL primary with a high-churn table growing 5-15GB/month and no partitioning or archiving

A time-series or event log table grows indefinitely without a retention policy. Monthly storage cost compounds as data accumulates in the primary database, in read replicas, in automated backups, and in cloud object storage. A table that costs $50/month at year one can reach $600/month by year three: not from increased usage, but purely from accumulated history that no one reads and no one deleted.

PostgreSQL RDS primary + 2 read replicas + daily automated backups retained 35 days + CloudWatch logs

A batch import: data migration, nightly ETL, or bulk user onboarding: overwhelms the write path. Primary database I/O saturates, WAL generation spikes, and autovacuum falls catastrophically behind. Active application OLTP traffic experiences 5-20× latency elevation while the import runs, with no clear ceiling until the import completes.

PostgreSQL primary + application server pool + nightly batch import process