Quick answer
The Spring order service supplies the teaching workload, but the browser never contacts it or a database.
The lab advances aggregate requests through a deterministic teaching model. It can expose arithmetic pressure and evidence questions; it cannot measure a database, predict latency, size a pool, run a failover, calculate RPO or RTO, or verify production. Engine selection never changes the arithmetic.
Learning objectives
- Interpret pool, lock, retry, replica, and failover timeline fields while preserving request-count invariants.
- Translate each modeled risk into separate PostgreSQL 18 and MySQL 8.4 evidence requests.
Prerequisites
Complete the sixteen readings, especially connection pooling, isolation, replicas, failover, observability, and incident troubleshooting.
Shared relational contract
Inputs are finite teaching units: pool size, arrivals, transaction duration, contention percentage, lock hold, wait timeout, retry limit, replica reads and lag, failover step and pause, and total steps. The pure function validates every field and returns either a timeline or field errors. It makes no network request and stores nothing.
Six presets cover healthy bounded load, long transactions, lock timeouts, retry amplification, stale-read risk, and ambiguous writes during failover. Repeating an input returns exactly the same result.
PostgreSQL 18 boundary
When the model flags pressure, request pg_stat_activity, wait events, safe lock evidence, plan and transaction age, WAL and replication state, logs, and durable order records as appropriate. The model does not simulate tuples, vacuum, WAL, locks, the planner, or promotion.
MySQL 8.4 InnoDB boundary
Request Performance Schema thread and wait evidence, data locks, InnoDB transaction and status information, plans, binary-log and replication state, error logs, and durable order records. The model does not simulate undo, purge, redo, binary logging, InnoDB locking, or promotion.
Production failure scenario
The failover preset interrupts active work and marks outcomes ambiguous. Do not read that count as predicted loss. In a real incident, use stable idempotency identity and authoritative engine plus application evidence to classify each affected order before retry or compensation.
Common misconceptions
- A step is not a second.
- An arrival count is not measured throughput.
- Saturation is not a capacity recommendation.
- Replica-visible output is not a consistency guarantee.
- Recovery step is not RTO.
Decision checklist
- State which inputs are assumptions.
- Run the same preset twice to observe determinism.
- Identify which real evidence is absent.
- Keep PostgreSQL and MySQL evidence separate.
- Never execute production changes from a model result.
Related reading
Return to incident troubleshooting, run the database recovery lab, use the course and topic, deepen with database lock contention, and connect to observability for backend systems.
Official sources
- PostgreSQL 18 monitoring, accessed August 19, 2026.
- PostgreSQL 18 high availability, accessed August 19, 2026.
- MySQL 8.4 Performance Schema, accessed August 19, 2026.
- MySQL 8.4 replication, accessed August 19, 2026.