Monedula

Visualize Apache Kafka in the browser

Kafka Simulator: break a cluster and see why it reacts.

Change a setting or kill a broker, then step through what producers, brokers, replicas, consumers and the metrics that watch them do.

Scenario 03.2.1, canonical failure t+4.250s

Produce committed. Healthy: three replicas of every partition are in sync, so the producer's acks=all write commits.

Open this run in the playground

Watch acks=all cross the durability boundary.

RF=3, min.insync.replicas=2, acks=all. Kill one broker; the cluster degrades but writes still commit. Kill a second; durability cannot be satisfied, and produce fails with NotEnoughReplicas. The figure above is visualized from a real simulator run: it is the simulator's own canvas at each frame of scenario 03.2.1, drawn when the site is built. Below is what the second kill leaves in the log and in the metrics.

[t+14.802] produce_request → orders/p1
[t+14.803] leader: broker-1 (epoch 3)
[t+14.803] isr: [broker-1]
[ERROR]   NotEnoughReplicas - acks=all needs 2 in-sync replicas,
          but only 1 is currently in ISR.
MetricΔWasNow
UnderReplicatedPartitions+303
IsrShrinksPerSec+1.20.01.2
FailedProduceRequestsPerSec+4.20.04.2
LeaderElectionRateAndTimeMs - 03, 38ms

136 scenarios, each checked against a recorded run.

The curriculum, 16 modules

  1. Anatomy 8 scenarios
  2. Producers & EOS 13 scenarios
  3. Consumer groups 13 scenarios
  4. Replication 12 scenarios
  5. Transactions 10 scenarios
  6. Storage 12 scenarios
  7. KRaft 4 scenarios
  8. Operations 6 scenarios
  9. Chaos 6 scenarios
  10. Disaster recovery 22 scenarios
  11. Tiered storage 2 scenarios
  12. Schema registry 3 scenarios
  13. Authorization (ACLs & RBAC) 2 scenarios
  14. Share groups 9 scenarios
  15. Capstones 5 scenarios
  16. Terminal ops 9 scenarios

These 136 scenarios cover every pack shipped through v2.0 - Governance, queues & capstones - the complete 136-scenario library. The changelog lists what each pack added.

01 intro, 1 min
b1 b2 b3 RF=3 3 racks leader + 2 in-sync followers

Anatomy baseline

Anatomy

RF=3 across 3 racks. Read ISR, leader, follower, LEO, and HW on a healthy cluster.

02 core, 2 min
b1 b2 b3 min.ISR=2 · acks=all ISR 1 < min.ISR 2

Canonical failure

Replication

Kill two brokers under acks=all, min.ISR=2: the run shown above.

03 core, 2 min
acks=0 acks=1 acks=all tput / latency

acks trade-off

Producer

The same workload at acks=0, 1 and all, compared on throughput, latency and durability.

04 advanced, 3 min
b1 b2 b3 unclean.leader=true stale data loss

Unclean leader

Replication

Why unclean.leader.election.enable=true can silently lose data.

05 core, 2 min
retry under failure idempotent=off ← dup idempotent=on

Idempotence retry

Producer

Retry under failure - with and without idempotence. Watch a duplicate appear, then disappear.

06 intro, 1 min
min.insync.replicas 1 2 3 durability ↔ availability

min.ISR boundary

Replication

Move min.insync.replicas from 1 to 3 on a running cluster with one slider.

07 core, 2 min
b1 b2 b3 slow lag > lag.max.ms ISR shrinks

Slow follower

Replication

A slow follower drops out of ISR. How replica.lag.time.max.ms decides.

08 core, 2 min
cleanup.policy=compact a b a c a b → c a b ⌀ latest value per key + tombstone

Compaction

Anatomy

Repeated keys to a compact topic. Then a tombstone, and the key is gone.

Scenarios and free play share one playground.

Brokers, partitions, RF, min.ISR, racks, regions, timing and a deterministic seed are all yours to set, then share by URL.

  • Zoom - level of detail and pinch-to-zoom on a phone keep a growing cluster readable.
  • Frames - step every tick with a per-event inspector; entities link straight to the parts they touch.
  • WHY tab - live health checks explain why the cluster sits where it does.
  • Steps tab - a click-to-jump walkthrough of every frame, each captioned with what just happened.
Open the playground

Visualize your own Kafka cluster in the playground.

monedula-sim-link takes a read-only snapshot of a real Kafka cluster and prints a playground link that opens the simulator shaped like it. Its MCP server lets an AI agent build the same links.

monedula-sim-link connect --brokers localhost:9092 --topics orders,payments

What it models, and what it does not.

Modeled

  • Producer → leader → follower fetch → HW/LEO advance, across multiple topics
  • Producer tuning - acks, idempotence & max.in.flight ordering, compression (zstd/gzip/snappy), buffer.memory backpressure, byte-rate quotas, rack-aware partitioning (partitioner.rack.aware, KIP-1123)
  • Transactions & EOS - PIDs, sequences, LSO, zombie fencing
  • ISR membership, leader epoch, unclean leader election, throttled reassignment (replication.throttled.rate)
  • Retention - time- & size-based (retention.bytes), compaction & tombstones, tiered storage with local.retention.ms (KIP-405)
  • Consumer groups (eager & cooperative rebalances), static membership (KIP-345), share groups (KIP-932)
  • Control plane - KRaft quorum, controller epoch & failover, plus the pre-4.0 ZooKeeper control plane for comparison (Kafka 4.x has no ZooKeeper mode)
  • Multi-DC DR - stretched 2.5-DC / MRC, observer promote & demote, active-passive failover & failback, active-active; MirrorMaker 2 offset translation & checkpoints; Cluster Linking (offset-preserving mirror, promote, bidirectional switchover)
  • Schema Registry - subjects, versions, compatibility modes
  • Authorization - ACLs & RBAC (principal / resource / operation, role bindings, deny-by-default)
  • Hard kill, graceful shutdown, restart, slow follower, network partition
  • Real Kafka metric names, directionally correct

Not modeled

  • GC pauses, OS page cache, network buffers, byte-exact sizes
  • SASL, mTLS, encrypted transport - the auth handshake & wire crypto (ACL/RBAC authorization itself is modeled)
  • Kafka Streams & Connect - core broker/client protocol only
  • New in Kafka 4.4 - share-group dead-letter queues (KIP-1191) and delayed tiered-storage upload (KIP-1241)
  • Magnitudes of metric movement - calibrated direction, illustrative scale

Simplified. 28 behaviors differ from Kafka 4.4 on purpose, such as batch.size counting records and timeouts shortened so a scenario plays in seconds, and the scenarios say so where it matters. See the fidelity page.

Modeled baseline: Apache Kafka 4.4. Not for production-as-is.

Part of Monedula Flock

The same people build tools for real clusters.

The simulator is where we explain Kafka. These are what we reach for when the cluster is not a simulation.

About Flock

Questions

Does anything leave my browser?
Nothing about your scenarios or actions is sent anywhere. The site counts page views with cookieless analytics (GoatCounter), as every page on monedula.dev does.
Which Kafka version does it model?
Apache Kafka 4.4.
How faithful is it?
It models how Kafka behaves, approximates some things by their effect, and leaves others out, such as GC pauses and the page cache. The fidelity page lists what is modeled, approximated and left out.
Can an application connect to it like a Kafka emulator?
No. It models how a cluster behaves; it does not speak the Kafka protocol. For a local broker, run Apache Kafka in Docker.
Can I see my own cluster?
Does it work on a phone?
Yes. On a phone the cluster is drawn as a vertical stack you can pinch to zoom, the details open in a bottom sheet that always shows the current step, and the secondary actions fold into a menu in the top bar.
How often do new packs ship?
The simulator grows in numbered releases, each a themed pack of scenarios and free-play features. The roadmap lists every version and its theme.

What ships next

Shipped v2.0 - Governance, queues & capstones

Built by Monedula. Apache Kafka and Kafka are trademarks of The Apache Software Foundation. Monedula Kafka Simulator is an independent educational tool and is not endorsed by or affiliated with The Apache Software Foundation.