---
title: "Kafka Simulator v1.4 — semántica de entrega, transacciones y activo/activo"
date: 2026-08-24T00:00:00.000Z
author: "michal"
excerpt: "Exactly-once, read_committed y el last stable offset, begin/commit/abort y el bucle consume–process–produce. El módulo de transacciones convierte EOS — el tema más difícil de Kafka — en algo que puedes recorrer paso a paso. El modo libre también estrena un nuevo tipo de clúster: activo/activo."
---
v1.4 añade el módulo de **transacciones** al [Kafka Simulator](/kafka-simulator/) — **10 escenarios nuevos** sobre el tema que más asentimientos provoca entre ingenieros y que menos veces llegan a ver de verdad: la semántica exactly-once. El temario alcanza **55 de 125**.

## Qué trae la v1.4

Las transacciones convierten un flujo de escrituras en una unidad atómica, y cambian lo que un consumidor tiene permitido ver:

- **`read_committed` y el last stable offset (LSO)** — por qué un consumidor transaccional lee hasta el LSO y no hasta el high watermark, y cómo una transacción abierta mantiene ese techo en su sitio.
- **begin / commit / abort** — el ciclo de vida transaccional del productor como una máquina de estados que tú mismo conduces, incluido lo que un marcador de abort hace con los registros que cubre.
- **El bucle consume–process–produce** — `sendOffsetsToTransaction`, y por qué confirmar los offsets *dentro* de la transacción es lo que hace real el exactly-once de extremo a extremo.
- **Fencing** — cómo un productor zombi queda excluido por época, y por qué esa es la red de seguridad bajo todo el modelo.

Exactly-once cuesta enseñarlo porque gran parte es invisible: marcadores, el LSO, las épocas y un consumidor que se salta en silencio los registros abortados. El simulador lo pone todo en la línea de tiempo — puedes ver cómo el LSO se queda quieto bajo una transacción abierta y salta hacia delante en el instante en que confirma.

## Nuevo tipo de clúster en modo libre: activo/activo

La escalera de topologías que empezó en la v1.3 con activo/pasivo sigue creciendo: el selector de clúster del modo libre gana una tercera forma — **Activo / activo**: dos regiones, ambas aceptando escrituras, cada una replicando hacia la otra.

No es, deliberadamente, «activo/pasivo con la flecha duplicada». El preset es *simétrico*:

- **Cada región es dueña de su propio topic.** `west` posee `west.orders`, `east` posee `east.orders`, y cada uno se replica en solo lectura hacia la otra región — así ambos lados guardan el flujo completo sin ambigüedad sobre quién puede escribir bajo el mismo nombre.
- **Cada región escribe en local y lee en global.** Un productor solo escribe en el topic de su propia región; el grupo de consumidores de cada región lee tanto el topic local como la copia replicada, de modo que cada registro se ve una vez por lado.
- **Cada región es su propio clúster.** Ambas ejecutan un quórum KRaft independiente, así que puedes matar los controladores de una región — o la región entera — y observar qué puede y qué no puede hacer el lado superviviente.

Ese último punto es el contraste afilado con las garantías transaccionales que enseña este pack: exactly-once es una promesa *por clúster*, y un par activo/activo son dos clústeres. Todo lo que te da el módulo de transacciones se sostiene dentro de una región y se detiene en el mirror.

El *temario* de DR que explica estas formas sigue llegando en la v1.8 — los sandboxes aterrizan antes a propósito, para que tengas dónde probar las ideas antes de que los escenarios las narren.

## Sobre los cimientos de la replicación

Este pack se apoya directamente en la v1.3. Una transacción es una garantía de durabilidad con atomicidad añadida encima, así que el ISR y el high watermark que aprendiste a leer allí siguen siendo la verdad de fondo aquí — el LSO no es más que un techo más estricto por encima de ellos.

Abre el [simulador](/kafka-simulator/), inicia una transacción, produce dentro de ella y abórtala — y mira después qué ve y qué no ve un consumidor `read_committed`.