Zum Hauptinhalt springen
tsecurity.de LIVE
Echtzeit-Radar & Feeds
Alle RSS Feeds
👥 Community & Social
Sichere ProgrammierungTCP vs UDP: The Two Ways to Move Data, and Why Neither Is "Better"(21.09.2026 um 09:31 Uhr)
Sichere ProgrammierungBukan Sekadar Variabel, Tapi Nyawa dari Aplikasi Kamu! 🚀(21.09.2026 um 09:36 Uhr)
Sichere ProgrammierungAI voice agent for customer service: what stops callers hanging up?(21.09.2026 um 09:42 Uhr)
Sichere ProgrammierungReading a small model's confidence instead of its prose(21.09.2026 um 09:47 Uhr)
Sichere ProgrammierungTCP vs UDP: The Two Ways to Move Data, and Why Neither Is "Better"(21.09.2026 um 09:31 Uhr)
Sichere ProgrammierungBukan Sekadar Variabel, Tapi Nyawa dari Aplikasi Kamu! 🚀(21.09.2026 um 09:36 Uhr)
Sichere ProgrammierungAI voice agent for customer service: what stops callers hanging up?(21.09.2026 um 09:42 Uhr)
Sichere ProgrammierungReading a small model's confidence instead of its prose(21.09.2026 um 09:47 Uhr)
Intelligence View
⚡ tsecurity.de Intelligence

I Built an Interactive Kafka Playground (Partitions, Keys, Consumer Groups, Offsets)

Kafka's pieces are each simple — partitions, keys, consumer groups, offsets, lag — but together they tie people in knots. So I built an interactive playground where you produce and consume and watch it happen, no broker required. ▶ Live de…

0
↗ Quelle (dev.to)
Reagiere als Erste:r — dein Feedback zählt!

Kafka's pieces are each simple — partitions, keys, consumer groups, offsets, lag — but together they tie people in knots. So I built an interactive playground where you produce and consume and watch it happen, no broker required.



▶ Live demo: https://dev48v.github.io/kafka-playground/

Source (single file, zero deps): https://github.com/dev48v/kafka-playground





The four ideas, made visible



1. Keys decide partitions. Produce a message with a key and it's hashed to a partition — and the same key always goes to the same partition:




key = "user-42"  →  hash("user-42") % partitionCount  →  Partition 0  (every time)






That single fact is why Kafka can only guarantee ordering within a partition, not across the topic. All of user-42's events stay ordered because they're all in one partition. Produce with no key and messages spread round-robin — faster fan-out, no per-key ordering.



2. A consumer group splits the partitions. Every partition is owned by exactly one consumer in the group. Add a consumer and the partitions rebalance across the group — that's how you scale out consumption.



3. More consumers than partitions = idle consumers. Give a 3-partition topic a 4th consumer and it just sits there. Partitions are the unit of parallelism, so your consumer count is capped by your partition count. Seeing the idle consumer light up grey makes this stick instantly.



4. Offsets and lag. Consuming advances the group's committed offset per partition. The gap between the newest message and the committed offset is lag. Produce faster than you consume and watch lag climb; flip on auto-consume and watch it drain.






Why a playground beats a diagram



You can read "partitions are the unit of parallelism" and still be surprised the first time a consumer goes idle. Dragging the consumer count past the partition count and seeing it happen teaches it in one move. Same with key stickiness — produce three messages with the same key, watch them stack in one partition, and the ordering guarantee stops being abstract.



It's one index.html. A deliberately simplified model (round-robin assignment vs Kafka's range/sticky/cooperative assignors; a small key hash vs murmur2) — but the behaviour you see matches real Kafka.



If this made Kafka click, a star helps others find it: https://github.com/dev48v/kafka-playground

Ähnliche Beiträge
🔍 Verwandte News

Auch interessante Nachrichten I Built an Interactive Kafka Playground (Partitions, Keys, Consumer Groups, Offsets)

Thematisch verwandte Begriffe: Built, Interactive, Kafka, Playground · 6 Treffer

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Zum Aktualisieren ziehen
ZERO-DAY CVE-2026-94030 | A security vulnerability has been detected in SerenityOS up to 3d83e4509…
Advisory →
TTS Reader • tsecurity.de Voice
tsecurity.de Icon
tsecurity.de App
Offline-Lesen, Eilmeldungen & 0ms Ladezeit

Installiere tsecurity.de direkt auf deinen Home-Bildschirm für das ultimative Vollbild-Magazinerlebnis ohne Browser-Leisten.

Nächster Beitrag
Themen-Radar & Intelligence Matrix
Echtzeit-Taxonomie nach Angriffsvektoren & Plattformen

tsecurity.de Live Threat Radar

🔴 LIVE RADAR
MONITORING
AKTIV
CVE-DATENBANK
LIVE
🔍
Community Radar & Live Chat
Sentinel Bot online • Live-Stream
Dein Cluster: Security Explorer
Match:
lädt…
Verbindung zum Community-Stream wird aufgebaut...
Bearbeitungsmodus — Senden überschreibt deine Nachricht
Community-Puls — was gerade passiert
lädt…
Aktivitäten deiner Analysten
lädt…
Neues Thema oder Eilmeldung einreichen

Reiche interessante Links, Zero-Days oder Debatten ein. Die Community entscheidet per Upvote über die Veröffentlichung.

Heiß diskutierte Einreichungen
🔖 Gespeicherte Artikel
📂 Keine gespeicherten Artikel vorhanden.
Zurück Ziehen Vor
Links: vorheriger Artikel Rechts: nächster Artikel unten: schließen
News NIS-2 Frühwarnung Tier-1 Intel ⏱️ 3 Min vor 10 Min
Artikeldaten werden geladen...

Zurück: vorheriger Vor: nächster
↗ Original-Quelle
Social Reaktionen Deine Reaktion zählt
Einstufung & Relevanz-Poll 0 Stimmen
In sozialen Netzwerken teilen 1-Klick