Kafka borra cada mensaje en cuanto un consumidor lo lee.

Falso. Kafka es un log: guarda los mensajes según la política de retención (tiempo o tamaño). Cada grupo de consumidores avanza su propio offset.

Kafka garantiza el orden de los mensajes dentro de una partición, pero no entre particiones.

Verdadero. Por eso, si el orden importa, se usa una clave que envíe los mensajes relacionados a la misma partición.

Dentro de un consumer group, cada partición la lee como máximo un consumidor del grupo a la vez.

Verdadero. Así se reparte el trabajo sin duplicarlo. Otro grupo distinto lee las mismas particiones por su cuenta.

Si un consumer group tiene más consumidores que particiones, los que sobran se quedan sin trabajo.

Verdadero. El número de particiones marca el máximo de paralelismo de un grupo.

Con el particionador por defecto, los mensajes con la misma clave van siempre a la misma partición, mientras no cambie el número de particiones.

Verdadero. La partición sale del hash de la clave. Si añades particiones, el reparto cambia.

En RabbitMQ, un exchange `fanout` copia cada mensaje en todas las colas enlazadas e ignora la routing key.

Verdadero. Es el patrón publish/subscribe de RabbitMQ. `direct` y `topic` sí usan la routing key.

Con acknowledgements manuales en RabbitMQ, un mensaje sin confirmar se pierde si el consumidor se cae.

Falso. Si el canal se cierra sin `ack`, el broker vuelve a encolar el mensaje para que lo procese otro consumidor.

Aplicar CQRS obliga a usar Event Sourcing.

Falso. Separar comandos y consultas no exige guardar eventos. Se combinan a menudo, pero son patrones independientes.

El patrón Outbox guarda el evento en la misma transacción de base de datos que el cambio de negocio.

Verdadero. Otro proceso publica después la tabla outbox en el broker. Así no hay cambios sin evento ni eventos sin cambio.

Con consistencia eventual, una lectura justo después de una escritura puede devolver datos antiguos.

Verdadero. Las réplicas o los modelos de lectura se ponen al día con retraso. La interfaz tiene que estar preparada para ese desfase.

Un consumidor de Kafka puede recibir el mismo mensaje más de una vez aunque todo funcione como está configurado por defecto.

Verdadero. La entrega por defecto es al menos una vez: si el consumidor cae o hay un rebalanceo antes de confirmar el offset, los mensajes posteriores al último offset confirmado se vuelven a entregar.

Un evento de integración debería llevar la entidad JPA completa serializada, así los consumidores tienen todos los datos.

Falso. Acopla a todos los consumidores a tu modelo interno: cualquier cambio en la entidad los rompe. Un evento de integración es un contrato estable y versionado con solo los datos necesarios.

En Event Sourcing, para corregir un evento erróneo ya guardado se edita su fila en el event store.

Falso. El event store solo admite añadir. Los errores se corrigen con un evento compensatorio, y así la historia y las proyecciones siguen siendo coherentes.

Una proyección de lectura se puede borrar y reconstruir reproduciendo los eventos desde el principio.

Verdadero. Toda la información está en los eventos; la proyección es una vista derivada. Por eso se puede corregir o crear una nueva sobre datos históricos.

Tras guardar un snapshot de un agregado se pueden borrar los eventos anteriores.

Falso. El snapshot es una optimización para cargar más rápido, no la fuente de verdad. Si tiene un error, solo los eventos permiten recalcularlo.

Quiz de la fase 6 Fase 6: Mensajería Asíncrona con Kafka, RabbitMQ, EDA y CQRS

¿Verdadero o falso?

15 afirmaciones sobre los días de esta fase. Responde cada una y lee la explicación: el fallo suele estar en un matiz.

0 de 15 respondidas
0 aciertos

Kafka borra cada mensaje en cuanto un consumidor lo lee.
Kafka garantiza el orden de los mensajes dentro de una partición, pero no entre particiones.
Dentro de un consumer group, cada partición la lee como máximo un consumidor del grupo a la vez.
Si un consumer group tiene más consumidores que particiones, los que sobran se quedan sin trabajo.
Con el particionador por defecto, los mensajes con la misma clave van siempre a la misma partición, mientras no cambie el número de particiones.
En RabbitMQ, un exchange fanout copia cada mensaje en todas las colas enlazadas e ignora la routing key.
Con acknowledgements manuales en RabbitMQ, un mensaje sin confirmar se pierde si el consumidor se cae.
Aplicar CQRS obliga a usar Event Sourcing.
El patrón Outbox guarda el evento en la misma transacción de base de datos que el cambio de negocio.
Con consistencia eventual, una lectura justo después de una escritura puede devolver datos antiguos.
Un consumidor de Kafka puede recibir el mismo mensaje más de una vez aunque todo funcione como está configurado por defecto.
Un evento de integración debería llevar la entidad JPA completa serializada, así los consumidores tienen todos los datos.
En Event Sourcing, para corregir un evento erróneo ya guardado se edita su fila en el event store.
Una proyección de lectura se puede borrar y reconstruir reproduciendo los eventos desde el principio.
Tras guardar un snapshot de un agregado se pueden borrar los eventos anteriores.