Pick your architecture, simulate a region failure, and see exactly what breaks, in what order — in plain English. A reasoning tool, not a live infrastructure test.
| Component | Status | RPO bandpotential data loss window | RTO bandestimated recovery time | Why |
|---|
No. It never connects to AWS, GCP, Azure, or any live system — it reasons through common failure patterns based on the architecture choices you select, entirely in your browser. Think of it as a napkin sketch for a conversation, not a substitute for a real game day or chaos engineering exercise.
Split-brain happens when a network partition leaves two regions individually healthy but unable to reach each other, and both keep accepting writes independently. If you select active-active topology with asynchronous replication and a network-partition failure, the simulator flags this because the two regions can silently drift into conflicting data that needs manual reconciliation once connectivity returns.
Asynchronous replication ships writes to the other region after acknowledging them to the client, so there's always a small window — the replication lag — where a confirmed write hasn't reached the surviving region yet. Only synchronous replication, which confirms the write in both regions before acknowledging it, eliminates this window, at the cost of added write latency all the time, not just during a failure.
This is a rule-based reasoning tool, not a monitoring or chaos-engineering product. It never contacts AWS, GCP, Azure, or any real system. Every dropdown you pick feeds a small set of independent reasoning modules — routing, data replication, compute, observability, and recovery — each of which writes a plain-English paragraph based on well-established multi-region architecture patterns. Nothing here is measured; it's reasoned through, the way an experienced architect would talk through a design on a whiteboard.
Active-active topology with asynchronous replication during a network partition is the textbook split-brain setup — both regions individually think they're fine and keep accepting writes, and there's no consensus mechanism in the picture to stop them from disagreeing. Asynchronous replication, on its own, always carries some data-loss window, because writes are acknowledged before they're confirmed in the other region. These aren't edge cases the tool invented — they're the tradeoffs every multi-region design has to make explicitly, and the simulator's job is to surface them for the specific combination you picked rather than let them stay implicit.
Use this before you design a game day, not instead of one — it's a fast way to sanity-check an architecture on paper, brief a team on what to expect, or spot a split-brain risk before it's built. It doesn't replace measuring actual DNS propagation in your account, actual replication lag under your write load, or actual autoscaling time for your cluster — those numbers only come from testing your real system.
Save and share your scenario as a permalink — coming soon