Quiz de Mensajería: SQS y Kafka

Quiz de Mensajería: SQS y Kafka

Pon a prueba tus conocimientos sobre mensajería distribuida, colas y streams de eventos.

1. 1. ¿Cuál es el propósito principal de una cola de mensajes en un sistema distribuido?

   • Almacenar datos permanentemente en una base de datos relacional
   • Desacoplar productores y consumidores para que puedan operar de forma independiente
   • Sincronizar peticiones HTTP entre microservicios
   • Proporcionar una caché compartida en memoria para los servicios

2. 2. En el modelo productor/consumidor, ¿cuál es el rol de un productor?

   • Lee y procesa mensajes de la cola
   • Gestiona la infraestructura de la cola y las reglas de enrutamiento
   • Envía mensajes a la cola para su procesamiento posterior
   • Supervisa la profundidad de la cola y activa el autoescalado

3. 3. ¿Qué es Amazon SQS?

   • Un servicio de base de datos relacional totalmente administrado de AWS
   • Un servicio de colas de mensajes totalmente administrado de AWS
   • Una plataforma distribuida de streaming de código abierto
   • Un motor de cómputo serverless para tareas por lotes

4. 4. ¿Cuál es la diferencia clave entre una cola SQS Standard y una cola SQS FIFO?

   • Las colas Standard garantizan orden estricto de los mensajes; las colas FIFO no
   • Las colas FIFO garantizan ordenación y procesamiento exactamente una vez (exactly-once); las colas Standard ofrecen ordenación por mejor esfuerzo y entrega al menos una vez (at-least-once)
   • Las colas Standard admiten cifrado; las colas FIFO no
   • Las colas FIFO son más económicas pero no tienen límites de rendimiento

5. 5. ¿Qué significa 'entrega al menos una vez' (at-least-once delivery) en un sistema de mensajería?

   • Un mensaje se entrega exactamente una única vez sin duplicados
   • Un mensaje puede entregarse más de una vez, por lo que los consumidores deben gestionar duplicados
   • Un mensaje solo se entrega si el consumidor está conectado
   • Un mensaje nunca se entrega más de una vez por grupo de consumidores

6. 6. ¿Qué es una Dead Letter Queue (DLQ)?

   • Una cola que elimina mensajes automáticamente después de 1 minuto
   • Una cola secundaria a la que se envían los mensajes tras fallar en su procesamiento un número determinado de veces
   • Una cola de alta prioridad destinada a alertas urgentes del sistema
   • Una cola que almacena únicamente metadatos sobre mensajes procesados

7. 7. ¿Qué es Apache Kafka?

   • Una base de datos relacional optimizada para datos de series temporales
   • Una plataforma distribuida de streaming de eventos diseñada para mensajería de alto rendimiento y tolerante a fallos
   • Un servicio de caché en memoria administrado por AWS
   • Una pasarela de API REST para comunicación entre microservicios

8. 8. ¿En qué se diferencia un topic de Kafka de una cola de mensajes tradicional?

   • Un topic elimina los mensajes de inmediato tras ser leídos por un consumidor
   • Un topic conserva los mensajes en un log para que múltiples grupos de consumidores independientes lean los mismos datos
   • Un topic solo admite un único productor a la vez
   • Un topic garantiza la entrega en menos de 1 segundo

9. 9. ¿Qué es un grupo de consumidores (consumer group) en Kafka?

   • Un conjunto de brokers que replican datos de partición
   • Una colección de consumidores que consumen conjuntamente un topic, leyendo cada uno de un subconjunto específico de particiones
   • Un grupo de administración que gestiona la creación y eliminación de topics
   • Un grupo de productores que comparten el mismo ID de cliente

10. 10. ¿Por qué es difícil garantizar un orden global estricto de mensajes a escala en sistemas de mensajería distribuida?

    • La latencia de red y el procesamiento en paralelo entre múltiples nodos dificultan imponer una secuencia global única sin generar un cuello de botella
    • El ordenamiento requiere una base de datos relacional, la cual los sistemas de mensajería no pueden usar
    • Las conexiones TCP alteran de manera inherente el orden de los paquetes
    • Los brokers de mensajería desordenan deliberadamente los mensajes para mejorar el rendimiento

11. 11. ¿Qué es el tiempo de espera de visibilidad (visibility timeout) de SQS y por qué es importante?

    • El tiempo máximo que un mensaje puede permanecer en la cola antes de ser eliminado automáticamente
    • El periodo durante el cual un mensaje recibido permanece oculto para otros consumidores, evitando el procesamiento duplicado
    • El retraso antes de que un mensaje recién enviado sea visible para los consumidores
    • La ventana de tiempo permitida para que un consumidor se autentique antes de leer un mensaje

12. 12. ¿Cuál es la ventaja de utilizar long polling frente a short polling en SQS?

    • El long polling comprime los mensajes para reducir el consumo de ancho de banda
    • El long polling mantiene la conexión abierta hasta 20 segundos, reduciendo respuestas vacías y disminuyendo costes
    • El long polling garantiza que los mensajes lleguen en estricto orden FIFO
    • El long polling permite a los consumidores enviar confirmaciones a SQS en tiempo real

13. 13. ¿Cuáles son los periodos de retención por defecto y máximo para una cola SQS?

    • Por defecto 1 día, máximo 7 días
    • Por defecto 4 días, máximo 14 días
    • Por defecto 7 días, máximo 30 días
    • Por defecto 1 hora, máximo 24 horas

14. 14. ¿Cómo habilitan las particiones de Kafka el paralelismo en el consumo de mensajes?

    • Cada partición se ejecuta en una región distinta de AWS para procesar geográficamente
    • A cada consumidor de un grupo se le asigna una o más particiones, permitiendo que varios consumidores lean distintas particiones de forma simultánea
    • Las particiones comprimen los mensajes para que cada consumidor procese el doble por segundo
    • Las particiones permiten a los productores escribir más rápido empaquetando mensajes en lotes

15. 15. ¿Cuál es la diferencia entre un offset confirmado (committed offset) y el último offset (latest offset) en Kafka?

    • El offset confirmado es el próximo mensaje a producir; el último offset es el último mensaje producido
    • El offset confirmado es la última posición confirmada como procesada por el grupo de consumidores; el último offset es el último mensaje escrito en la partición
    • El offset confirmado se guarda en disco; el último offset se almacena únicamente en memoria
    • Son términos sinónimos usados indistintamente en la documentación de Kafka

16. 16. ¿Qué provoca un rebalanceo (rebalance) de un grupo de consumidores en Kafka?

    • Que un administrador aumente el factor de replicación de un topic
    • Que un consumidor se una o abandone el grupo, o que expire el timeout de sesión, lo que ocasiona que las particiones se reasignen entre los consumidores activos
    • Que un productor envíe un mensaje que exceda el tamaño de lote configurado
    • Que la elección de líder en ZooKeeper complete una nueva ronda

17. 17. ¿Cuál es el propósito del factor de replicación en Kafka y qué significa ISR?

    • El factor de replicación define el TTL del mensaje; ISR significa Retención Sincronizada
    • El factor de replicación define cuántas copias en brokers existen por partición; ISR (In-Sync Replicas) es el conjunto de réplicas que están totalmente al día con el líder
    • El factor de replicación determina el número de grupos de consumidores; ISR monitoriza su retraso
    • El factor de replicación configura la compresión; ISR es el índice de registros almacenados

18. 18. ¿Qué configuración de Kafka permite lograr semántica de exactamente una vez (exactly-once semantics) de extremo a extremo?

    • Establecer acks=0 en el productor y activar auto-commit en el consumidor
    • Activar productores idempotentes (enable.idempotence=true) combinado con APIs transaccionales en productores y isolation.level=read_committed en consumidores
    • Utilizar un topic FIFO con una sola partición y un único consumidor
    • Desactivar el procesamiento por lotes y definir max.in.flight.requests.per.connection=1

19. 19. ¿Cuál es la diferencia fundamental entre Amazon SQS, Amazon SNS y Amazon EventBridge?

    • SQS es una cola para mensajería punto a punto; SNS es pub/sub para fan-out a múltiples suscriptores; EventBridge es un bus de eventos con reglas de enrutamiento y registro de esquemas
    • SQS es para streaming de datos; SNS es para procesamiento por lotes; EventBridge es exclusivo para IoT
    • Los tres son servicios idénticos con diferentes esquemas de precios
    • SNS almacena mensajes durante 14 días al igual que SQS; EventBridge no retiene eventos

20. 20. ¿Qué es la compactación de logs (log compaction) en Kafka y cuándo debe utilizarse?

    • Un proceso en segundo plano que comprime archivos de log con gzip para ahorrar espacio en disco
    • Una política de retención que conserva únicamente el último valor por cada clave, descartando registros antiguos con la misma clave
    • Una operación de Kafka Streams que combina dos topics en uno solo ordenado
    • Un proceso que borra todos los mensajes anteriores al periodo de retención configurado

21. 21. ¿Cuáles son los tres archivos que componen un segmento de log en Kafka y qué almacena cada uno?

    • .log almacena los bytes sin procesar del mensaje; .index mapea offsets a posiciones de bytes en .log; .timeindex mapea marcas de tiempo a offsets
    • .log almacena offsets; .index guarda los bytes de mensajes; .timeindex guarda metadatos de la partición
    • .log almacena el estado del grupo de consumidores; .index guarda IDs de productores; .timeindex guarda el lag de replicación
    • .log almacena lotes comprimidos; .index guarda IDs de esquemas; .timeindex guarda tiempos de expiración TTL

22. 22. ¿Qué es una partición caliente (hot partition) en Kafka y cómo la causa el particionamiento basado en claves?

    • Una partición caliente es aquella que recibe demasiadas réplicas; el enrutamiento por clave reparte réplicas de forma desigual
    • Una partición caliente recibe de forma desproporcionada más mensajes que otras porque una clave de alta frecuencia (ej.: ID de usuario popular) siempre calcula el hash hacia la misma partición
    • Una partición caliente queda temporalmente fuera de línea; el enrutamiento por clave la evita hasta que se recupera
    • Una partición caliente almacena datos compactados; el particionamiento round-robin evita la compactación

23. 23. ¿Cómo se manifiesta el back-pressure en una cadena de consumidores de Kafka y cuál es una estrategia habitual de mitigación?

    • El back-pressure aparece como limitación (throttling) en el productor; la mitigación es incrementar la cantidad de topics
    • El back-pressure se manifiesta como un crecimiento del consumer lag cuando el procesamiento es más lento que la tasa de producción; las mitigaciones incluyen añadir consumidores hasta igualar las particiones, incrementar particiones o limitar al productor
    • El back-pressure se manifiesta como saturación de disco en el broker; la mitigación es habilitar la compactación de logs
    • El back-pressure se manifiesta como timeouts de ZooKeeper; la mitigación es actualizar al modo KRaft

24. 24. ¿En qué se diferencia Kafka Streams de Apache Flink y Apache Spark Structured Streaming para el procesamiento de streams con estado (stateful)?

    • Kafka Streams es un framework por lotes; Flink y Spark son motores puros de streaming
    • Kafka Streams es una biblioteca cliente que corre dentro de tu aplicación sin un cluster independiente; Flink y Spark son frameworks distribuidos independientes con gestión propia de recursos
    • Kafka Streams requiere Kubernetes; Flink y Spark operan únicamente sobre servidores dedicados
    • Kafka Streams no soporta operaciones con estado; Flink y Spark sí lo hacen

25. 25. ¿Cuál es el límite de procesamiento de una cola SQS FIFO y de qué forma influyen los Message Group IDs?

    • Las colas FIFO soportan procesamiento ilimitado; los Message Group IDs no tienen efecto sobre el rendimiento
    • Las colas FIFO soportan hasta 300 mensajes/segundo (o 3.000 con lotes); los mensajes con el mismo Group ID se procesan en serie, por lo que más Group IDs distintos permiten mayor paralelismo
    • Las colas FIFO soportan 10.000 mensajes/segundo; cada Group ID añade 1.000 mensajes/segundo de capacidad
    • Las colas FIFO soportan hasta 1.000 mensajes/segundo sin importar los Group IDs

26. 26. ¿Por qué es importante un registro de esquemas (schema registry) al usar Avro o Protobuf con Kafka y qué problema resuelve?

    • Un schema registry cifra los mensajes en tránsito; sin él, las cargas Avro se transmiten en texto plano
    • Un schema registry centraliza el control de versiones para que productores y consumidores evolucionen de forma independiente manteniendo compatibilidad, e incluye solo el ID del esquema en la carga útil
    • Un schema registry es un plugin del broker Kafka que valida límites de tamaño de mensaje
    • Un schema registry sustituye a ZooKeeper en la gestión de metadatos de cluster en versiones recientes

27. 27. ¿Qué métricas y herramientas se utilizan habitualmente en producción para monitorizar el consumer lag de Kafka?

    • El consumer lag solo puede consultarse en la interfaz web nativa de Kafka
    • El consumer lag se monitoriza con kafka-consumer-groups.sh, métricas JMX de Kafka (records-lag-max), Prometheus con kafka-exporter o el exportador JMX de Confluent, y plataformas como Datadog o Grafana
    • El consumer lag solo se puede ver en AWS CloudWatch cuando se utiliza Amazon MSK
    • El consumer lag se rastrea leyendo el topic __consumer_offsets de forma directa desde el código de la aplicación

28. 28. ¿Qué es el patrón Transactional Outbox y cómo soluciona el problema de escritura dual (dual-write) entre una base de datos y un broker de mensajería?

    • El patrón outbox almacena mensajes en una cola SQS FIFO antes de escribir en la base de datos, asegurando que la base solo cambie si la cola acepta el mensaje
    • El patrón outbox guarda el cambio de estado de dominio y el mensaje de salida en la misma transacción de base de datos; un proceso repetidor independiente lee la tabla outbox y publica en el broker, garantizando atomicidad sin transacciones distribuidas
    • El patrón outbox utiliza confirmación en dos fases (two-phase commit) entre la base de datos y Kafka para garantizar escrituras simultáneas
    • El patrón outbox almacena mensajes en la memoria de la aplicación y los envía a Kafka después de hacer commit en la base de datos

29. 29. ¿Qué es Kafka Connect y cuáles son sus dos tipos principales de conectores?

    • Kafka Connect es una biblioteca cliente para crear grupos de consumidores personalizados; sus dos tipos son de sondeo (polling) y push
    • Kafka Connect es un framework para transmitir datos de forma escalable entre Kafka y sistemas externos; los conectores Source importan datos a Kafka y los Sink exportan datos desde Kafka a destinos externos
    • Kafka Connect es una herramienta de monitorización; sus tipos de conectores son de métricas y de logs
    • Kafka Connect es una extensión del registro de esquemas; sus conectores son de tipo Avro y Protobuf

30. 30. ¿En qué se diferencia la replicación entre regiones mediante fan-out con SQS y Kafka MirrorMaker 2?

    • El fan-out de SQS y MirrorMaker 2 son idénticos funcionalmente; la elección se basa exclusivamente en costes
    • El fan-out de SQS utiliza SNS para distribuir mensajes a colas en múltiples regiones simultáneamente (activo-activo), mientras que MirrorMaker 2 replica asíncronamente topics y offsets de grupos de consumidores entre clusters, admitiendo topologías activo-activo y activo-pasivo
    • El fan-out de SQS replica mensajes con Kafka Connect; MirrorMaker 2 utiliza AWS DataSync
    • MirrorMaker 2 opera únicamente con semántica exactly-once; el fan-out de SQS solo con at-most-once