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

> 15 afirmaciones de verdadero o falso, con la respuesta explicada, sobre los días de esta fase del plan JavaMastery.

Versión interactiva: https://aprende-java.webs-economicas.es/quiz/fase-6/

## Afirmaciones

### 1. Kafka borra cada mensaje en cuanto un consumidor lo lee.

**Respuesta:** 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.

**Para recordarlo:** Kafka guarda los mensajes; los consumidores solo mueven su offset.

Se estudia en el [día 22: Mensajería Asíncrona con Apache Kafka y Spring Boot 3](https://aprende-java.webs-economicas.es/dias/kafka-spring-boot.md).

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

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

**Para recordarlo:** ¿Necesitas orden? Misma clave, misma partición.

Se estudia en el [día 22: Mensajería Asíncrona con Apache Kafka y Spring Boot 3](https://aprende-java.webs-economicas.es/dias/kafka-spring-boot.md).

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

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

**Para recordarlo:** En un grupo, cada partición tiene un solo lector a la vez.

Se estudia en el [día 22: Mensajería Asíncrona con Apache Kafka y Spring Boot 3](https://aprende-java.webs-economicas.es/dias/kafka-spring-boot.md).

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

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

**Para recordarlo:** Paralelismo máximo de un grupo = número de particiones.

Se estudia en el [día 22: Mensajería Asíncrona con Apache Kafka y Spring Boot 3](https://aprende-java.webs-economicas.es/dias/kafka-spring-boot.md).

### 5. 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.

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

**Para recordarlo:** Elige el número de particiones pensando en el futuro: cambiarlo reparte las claves de otra forma.

Se estudia en el [día 22: Mensajería Asíncrona con Apache Kafka y Spring Boot 3](https://aprende-java.webs-economicas.es/dias/kafka-spring-boot.md).

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

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

**Para recordarlo:** `fanout` = a todas las colas; `direct` = clave exacta; `topic` = clave con comodines.

Se estudia en el [día 23: RabbitMQ, Patrones de Mensajería y Comparativa Estratégica con Kafka](https://aprende-java.webs-economicas.es/dias/rabbitmq-vs-kafka.md).

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

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

**Para recordarlo:** Sin `ack` no hay pérdida: el mensaje vuelve a la cola. Por eso los consumidores deben ser idempotentes.

Se estudia en el [día 23: RabbitMQ, Patrones de Mensajería y Comparativa Estratégica con Kafka](https://aprende-java.webs-economicas.es/dias/rabbitmq-vs-kafka.md).

### 8. Aplicar CQRS obliga a usar Event Sourcing.

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

**Para recordarlo:** CQRS separa lecturas y escrituras; Event Sourcing guarda eventos. Se pueden usar por separado.

Se estudia en el [día 25: CQRS y Event Sourcing: Modelos de Lectura y Estado como Historia](https://aprende-java.webs-economicas.es/dias/cqrs-event-sourcing.md).

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

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

**Para recordarlo:** Outbox: escribe el evento en tu base de datos, en la misma transacción, y publícalo después.

Se estudia en el [día 24: Arquitectura Orientada a Eventos y Patrón Outbox](https://aprende-java.webs-economicas.es/dias/arquitectura-eventos-outbox.md).

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

**Respuesta:** 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.

**Para recordarlo:** Consistencia eventual: diseña la interfaz contando con un pequeño retraso entre escribir y leer.

Se estudia en el [día 24: Arquitectura Orientada a Eventos y Patrón Outbox](https://aprende-java.webs-economicas.es/dias/arquitectura-eventos-outbox.md).

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

**Respuesta:** 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.

**Para recordarlo:** Diseña cada consumidor como si los duplicados fueran seguros: lo son.

Se estudia en el [día 24: Arquitectura Orientada a Eventos y Patrón Outbox](https://aprende-java.webs-economicas.es/dias/arquitectura-eventos-outbox.md).

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

**Respuesta:** 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.

**Para recordarlo:** Evento de integración = API pública: estable, versionado y mínimo.

Se estudia en el [día 24: Arquitectura Orientada a Eventos y Patrón Outbox](https://aprende-java.webs-economicas.es/dias/arquitectura-eventos-outbox.md).

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

**Respuesta:** 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.

**Para recordarlo:** Como en un extracto bancario: no se borra el cargo, se añade la devolución.

Se estudia en el [día 25: CQRS y Event Sourcing: Modelos de Lectura y Estado como Historia](https://aprende-java.webs-economicas.es/dias/cqrs-event-sourcing.md).

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

**Respuesta:** 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.

**Para recordarlo:** Proyección = vista desechable; los eventos, la fuente de verdad.

Se estudia en el [día 25: CQRS y Event Sourcing: Modelos de Lectura y Estado como Historia](https://aprende-java.webs-economicas.es/dias/cqrs-event-sourcing.md).

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

**Respuesta:** 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.

**Para recordarlo:** Snapshot = caché del estado; nunca sustituye a los eventos.

Se estudia en el [día 25: CQRS y Event Sourcing: Modelos de Lectura y Estado como Historia](https://aprende-java.webs-economicas.es/dias/cqrs-event-sourcing.md).