Database replication simulator
The problem
One database server is a single point of failure and a limit on read traffic. Replicas copy the primary's changes so they can serve reads and take over if it fails. But copying takes time, so a replica can be behind, and a failover can lose writes the primary had already confirmed.
What you will see
See how replication delay turns into stale reads, why reading from the primary avoids them at the cost of load, and how asynchronous and synchronous commit trade write latency against losing acknowledged writes in a failover.
A primary database and two read replicas with replication delay. Send reads to replicas, watch stale reads appear, and fail the primary to see what asynchronous and synchronous commit mean for a failover.