--- title: "Kafka Simulator v2.0 - el temario completo y un playground reconstruido" date: 2026-10-21T00:00:00.000Z author: "michal" excerpt: "v2.0 completa los 136 escenarios: Schema Registry y autorización, con un nivel de gobernanza para el free play, share groups (KIP-932), topics diskless (el borrador de KIP-1163/1164) y los capstones. El playground que los rodea se ha reconstruido - tres formas de ver un clúster, una línea de tiempo que se puede leer, inspectores que responden preguntas y un terminal que ya no tapa el lienzo." --- v2.0 es el último paquete del temario. Añade cuatro módulos - **schema-registry**, **authorization**, **share-groups** y **capstones** - además de tres escenarios de **topics diskless** en el módulo storage, un simulacro de DR active-active en el módulo dr y el particionado consciente del rack en el módulo producer, **24 escenarios nuevos** en total. Desbloquea los niveles **governance** y **diskless** en el free play y completa el temario del [Kafka Simulator](/kafka-simulator/) con **136 de 136**. También es la versión en la que se ha reconstruido el playground que rodea esos escenarios. Desde la v1.9 ha cambiado casi todo: el lienzo tiene tres vistas, la línea de tiempo se ha convertido en algo que se puede leer, los inspectores responden preguntas en lugar de listar campos y el terminal ya no tapa el lienzo. ## Qué trae la v2.0 **Schema Registry (`schema-registry`, 3 escenarios).** [Subjects y versiones](/kafka-simulator/scenarios/subjects-and-versions/), [qué comprueban las compatibilidades backward, forward y full](/kafka-simulator/scenarios/compatibility-modes/), y [un cambio incompatible rechazado antes de registrarse](/kafka-simulator/scenarios/breaking-change-rejected/). **Autorización (`authorization`, 2 escenarios).** Control de acceso en el camino de datos - cómo [una ACL](/kafka-simulator/scenarios/acls-authorizing-a-producer/), o [un role binding de RBAC](/kafka-simulator/scenarios/rbac-role-bindings/), permite o deniega un produce cuando el autorizador deniega por defecto. Ambos llegan al free play con el nuevo **nivel de gobernanza**: Schema Registry, controles de ACL y RBAC, y `kafka-acls` en el terminal, para que puedas reconstruir y romper a mano todo lo que muestran los escenarios. **Share groups (`share-groups`, 9 escenarios).** [La semántica de colas de Kafka](/kafka-simulator/scenarios/share-group-queue/), introducida en KIP-932: - Cómo un share group permite que [muchos consumidores trabajen sobre una sola partición](/kafka-simulator/scenarios/cooperative-beyond-partitions/), confirmando los registros uno a uno en lugar de por offset confirmado. - [Adquirir, confirmar y liberar](/kafka-simulator/scenarios/acknowledge-accept-release-reject/) - el ciclo de vida por registro que hay detrás del consumo al estilo de una cola. - Límites de entrega y [el camino del poison pill](/kafka-simulator/scenarios/share-group-poison-pill/) - cómo un registro que no deja de fallar se archiva en lugar de reentregarse para siempre. Los share groups cambian la forma de consumir de Kafka, y verlos junto a los grupos de consumidores clásicos muestra qué es lo que cambia. **Capstones (`capstones`, 5 escenarios).** Escenarios de extremo a extremo que combinan durabilidad, transacciones, almacenamiento, multi-DC y gobernanza, con más de una cosa ocurriendo a la vez: [un pipeline de pagos exactly-once que sobrevive a la pérdida de una región](/kafka-simulator/scenarios/exactly-once-payments-pipeline/), [un failover regional sin pérdida de datos](/kafka-simulator/scenarios/survive-regional-outage-zero-loss/), [una migración sin tiempo de inactividad con Cluster Linking](/kafka-simulator/scenarios/migrate-with-cluster-linking/), [una columna vertebral de eventos activo/activo multi-DC](/kafka-simulator/scenarios/active-active-event-backbone/), y [un pipeline ajustado a la vez para throughput y latencia](/kafka-simulator/scenarios/tune-high-throughput-low-latency/). **Recuperación ante desastres (`dr`, 1 escenario más).** [Un simulacro de DR active-active](/kafka-simulator/scenarios/active-active-dr-drill/): se pierde la región west, su productor y su grupo de consumidores pasan a east y siguen escribiendo, y después west se reinicia y vuelven a casa. No se promueve nada, y los registros que west nunca replicó son el precio. **Productor (`producer`, 1 escenario más).** [Particionado consciente del rack](/kafka-simulator/scenarios/rack-aware-partitioning/), nuevo en Kafka 4.4: un productor mantiene sus registros sin clave en su propia zona de disponibilidad, hasta que esa zona pierde sus líderes. Más detalles abajo, en Apache Kafka 4.4. ## Topics diskless (dirección de KIP-1150, borrador de KIP-1163/1164) Un topic diskless guarda los datos de sus particiones en el almacenamiento de objetos en lugar de en los discos de los brokers. Un broker acumula registros de muchas particiones y los sube como un único objeto WAL; un coordinador diskless asigna los offsets al confirmar ese objeto, y el produce se confirma (ack) en ese commit. Las réplicas construyen su log releyendo el objeto desde el almacenamiento en lugar de hacer fetch al líder, y productores y consumidores usan una réplica de su propia zona de disponibilidad. El estado actual: [KIP-1150](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1150%3A+Diskless+Topics) está aceptado como dirección, mientras que [KIP-1163](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1163%3A+Diskless+Core) y [KIP-1164](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1164%3A+Diskless+Coordinator), que definen cómo funciona, siguen en Under Discussion ([KAFKA-19161](https://issues.apache.org/jira/browse/KAFKA-19161) sigue la implementación). Modelamos el borrador actual y lo marcamos como "KIP draft" en todo el simulador. Los nombres y el comportamiento pueden cambiar antes de que nada de esto llegue a Kafka. **Tres escenarios (`storage`, 05.4.1-05.4.3):** - **[Diskless: el camino de escritura](/kafka-simulator/scenarios/diskless-write-path/)** - dos productores y dos particiones comparten un objeto WAL, no existe ningún offset hasta que el coordinador lo confirma, y las réplicas releen los datos desde el almacenamiento de objetos. - **[Sin replicación entre AZ](/kafka-simulator/scenarios/no-cross-az-replication/)** - los mismos 3 registros van a un topic clásico y a uno diskless repartidos en tres AZ; la tarjeta Cross-AZ traffic termina con 7 saltos en el clásico y 0 en el diskless. - **[El precio es la latencia](/kafka-simulator/scenarios/diskless-produce-latency/)** - el mismo produce con `acks=all` se confirma en 300 ms en un topic clásico y en 1300 ms en uno diskless, mientras que una ráfaga que llena el búfer se confirma en 800 ms. Los tiempos están ampliados para que cada paso sea visible. **En el free play:** un preset **Diskless 3 AZ**, un interruptor diskless por topic y deslizadores para los tiempos de diskless. El lienzo gana un carril de almacenamiento de objetos con su propio eje temporal, bandejas WAL bajo cada broker y una insignia del coordinador, y el panel de métricas una tarjeta **Cross-AZ traffic**. En el terminal, `kafka-topics --create --config diskless.enable=true` crea un topic diskless y `kafka-diskless-metadata` (también una herramienta en borrador, que aún no está en Apache Kafka) muestra los offsets por partición y lista los objetos WAL del almacenamiento. El compromiso, en resumen: menos tráfico de replicación entre AZ y produces más lentos - el borrador apunta a una latencia de produce de unos 500 ms en P50 y de 1-2 s en P99. Kafka clásico ya puede leer de un follower de la misma AZ (KIP-392), así que lo que aporta diskless es que no hay replicación entre brokers y que un produce no tiene que llegar al líder. ## Apache Kafka 4.4 El modelo sigue ahora Apache Kafka 4.4, publicado esta semana. Comparamos 4.3.0 con 4.4.0 y no encontramos ningún valor por defecto, salida de la CLI ni mensaje de error en los que se apoye el simulador que haya cambiado, así que todo en los escenarios se comporta como antes. La v2.0 modela una novedad de 4.4: el particionado consciente del rack en el productor ([KIP-1123](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1123%3A+Rack-aware+partitioning+for+Kafka+Producer)). Con `partitioner.rack.aware=true` y un `client.rack`, el particionador por defecto envía los registros sin clave a particiones cuyo líder está en la zona de disponibilidad del productor, y a cualquier partición cuando esa zona no tiene líder, de modo que el tráfico de producción no sale de la zona. El nuevo escenario [Particionado consciente del rack](/kafka-simulator/scenarios/rack-aware-partitioning/) muestra los dos casos. En el free play, el inspector del productor tiene el interruptor, y los productores con los que arranca un sandbox pueden elegir su `client.rack`. Sin `client.rack`, el productor rechaza el ajuste, como en Kafka. Las colas de mensajes fallidos (dead-letter queues) de los share groups (KIP-1191), otra novedad de 4.4, aún no están modeladas. ## Un playground reconstruido ### Tres formas de ver un clúster El lienzo tiene ahora tres vistas, que se cambian desde su barra de herramientas: - **Brokers** es la imagen de siempre: productores a la izquierda, el clúster en el centro, grupos de consumidores y share groups a la derecha. - **Lanes** dibuja una fila por partición sobre un eje de offsets compartido: las réplicas una debajo de otra, el líder primero, y el high watermark como una sola línea que las atraviesa todas. Un follower rezagado tiene un log visiblemente más corto, el log de un broker detenido se queda quieto, y cada consumidor aparece en su posición de lectura con su offset confirmado y su lag. De un vistazo ves dónde está cada uno en el log. - **Matrix** es para clústeres demasiado grandes para dibujarlos: una tabla con los topics en filas y los brokers en columnas, y cuatro lentes - **Failures**, **Balance**, **Lag** y **Traffic** - que la colorean y la ordenan poniendo primero lo peor. Al pasar el ratón por un broker se ve qué perdería el clúster, topic por topic, antes de detenerlo. Un clúster grande de free play se abre directamente en Matrix. ### El lienzo muestra lo que ha cambiado Los cambios de estado se reproducen ahora sobre el elemento que ha cambiado en lugar de con un pulso genérico: los marcadores del high watermark se deslizan hasta su nuevo offset, la corona del líder pasa del líder antiguo al nuevo, y la etiqueta ISR de un follower toma el color del cambio. Un registro producido aterriza en su propia celda del log, un lienzo con mucha actividad dibuja los registros como estelas cortas, y un broker detenido se queda en el lienzo, atenuado, para que veas lo que había ahí. En los lienzos multirregión, el enlace de mirror muestra su RPO, cada franja de DC indica lo que costaría perderla, una partición de red muestra qué lado sigue sirviendo, la franja de KRaft cuenta su mayoría y el carril de un share group muestra el temporizador de bloqueo y el recuento de entregas de cada registro. ### Una línea de tiempo que se puede leer En el escritorio, el dock inferior es ahora un **rail** de una sola línea: los fotogramas se colocan en su tiempo real de simulación, de modo que una ráfaga se lee como un grupo y un tramo tranquilo como un hueco, y se recorre arrastrando sobre él. Abre sus **event lanes** y todos los eventos de la ejecución se reparten en carriles de produce, replicación, brokers y consumo, con los fallos en rojo y el evento principal de cada fotograma marcado. ### Inspectores que responden preguntas El panel derecho parte ahora de las preguntas que te haces. Una partición se lee como una regla de sus offsets, un broker como lo que pierdes cuando se detiene, un topic como un carril por partición, un productor como su camino de envío y un grupo de consumidores como carriles o como una cuadrícula de particiones. **Why** lista qué se ha roto y por qué, **Metrics** se agrupa por rol, y algunos inspectores muestran lo que va a pasar a continuación, no solo el estado actual. Las vistas multirregión ganan una tarjeta de DR que muestra el log de cada región y la cola sin replicar como RPO. ### El lienzo le hace sitio al terminal El terminal CLI de Kafka sigue acoplado bajo el lienzo, pero ahora el lienzo le hace sitio en lugar de quedar tapado por él - así que `kafka-server-stop` y la caída de broker-1 aparecen en pantalla a la vez, y el terminal tiene todo el ancho del lienzo para lo que escribes y lo que imprimen las herramientas. En una pantalla ancha, **dock side** en su barra de título lo pasa a una columna junto al lienzo. La salida conserva sus columnas y el menú de hosts es una tabla `ssh` con todos los brokers y controladores. Los archivos de configuración de los brokers coinciden con Kafka 4.4, y `kafka-reassign-partitions --generate`, junto con drenar un broker antes de retirarlo, funcionan como en un clúster real. ### Primeros pasos, sin tour El tour modal de 13 pasos ha desaparecido. En su lugar hay una tarjeta **Getting started** en una esquina del lienzo: los mismos temas como una lista de comprobación que recorres en el orden que quieras, cada uno con un "Show me". La ayuda es ahora una referencia en la que consultar cosas, un escenario guionizado se puede bifurcar en un sandbox con Undo, los escenarios sugieren sus propios movimientos de "Try it yourself" y qué hacer después, y un enlace compartido reproduce ahora cómo se llegó al estado que muestra. ### Un aspecto nuevo y un repaso de accesibilidad Todo el sitio, playground incluido, tiene un aspecto nuevo inspirado en la grajilla de nuestro nombre: tinta oscura, un brillo azul y gris, con todos los pares de colores de texto en WCAG AA. Con él llegaron enlaces para saltar al contenido y regiones con nombre, un rail de escenarios con una sola parada de tabulación, contraste AA para las regiones inactivas, respuesta visual al pulsar y áreas táctiles más grandes, y un movimiento que respeta `prefers-reduced-motion` conservando los fundidos y eliminando los desplazamientos. El diseño para móvil tuvo su propio repaso, hasta un test que comprueba que todas las etiquetas siguen cabiendo. ## Fuera del playground El playground en sí no es indexable, así que los buscadores nunca vieron el texto de sus escenarios. Ahora **cada escenario tiene su propia página** en [/kafka-simulator/scenarios/](/kafka-simulator/scenarios/): su introducción y su conclusión, cada paso con un enlace "Open at this step", un fotograma real del lienzo que puedes recorrer paso a paso y las configuraciones de Kafka que toca. Con la v2.0 son 136 páginas. Junto a ellas están las **[páginas de resolución de problemas](/kafka-simulator/troubleshooting/)** para errores y síntomas de Kafka: qué significa el problema, las causas probables, las soluciones y lo que no hay que hacer, y si el cliente lo reintenta. Cada una está enlazada a los escenarios en los que ocurre, abiertos justo en ese momento. La página de autorización se suma a ellas con esta versión. El [changelog](/kafka-simulator/changelog/) se lee ahora como notas de versión sobre una línea de tiempo. ## Una cosa más Hemos escondido algo en esta versión. Encontrarlo te lo dejamos a ti. ## El final de la hoja de ruta v2.0 completa lo que empezó con la v1.0: once paquetes quincenales, 136 escenarios, desde la anatomía de un único broker hasta las colas y los capstones de plataforma completa. Todo se ejecuta en el navegador, de forma determinista, con la semántica de Apache Kafka 4.4, sin backend y sin telemetría sobre tus escenarios. El temario está completo, pero el simulador es un sandbox, no un curso que se termina. Abre el [simulador](/kafka-simulator/), construye algo y rómpelo.