Mejores Prácticas de Configuración de Kafka para Entornos de Producción

Kafka es indulgente en desarrollo y mucho menos indulgente en producción. Un tema con una réplica funciona bien hasta que un broker falla. Un productor con confirmaciones débiles parece rápido hasta que los mensajes desaparecen durante una falla. Un consumidor que confirma automáticamente los offsets parece simple hasta que confirma trabajo que en realidad no ha terminado. La configuración de Kafka en producción se trata principalmente de decidir qué fallas está dispuesto a tolerar y luego hacer explícitas esas decisiones.

Esta guía cubre las mejores prácticas de configuración de Kafka para entornos de producción sin pretender que exista un archivo de configuración perfecto. La configuración correcta depende de la carga de trabajo, las necesidades de latencia, los requisitos de durabilidad, la madurez operativa y la versión de Kafka. Los ejemplos a continuación son puntos de partida que debe probar bajo su propio tráfico.

Comprensión de los Componentes Clave de Kafka y su Configuración

Antes de profundizar en configuraciones específicas, es crucial comprender los componentes centrales de Kafka y cómo sus ajustes impactan el comportamiento general del sistema.

Brokers: Los servidores de Kafka que almacenan datos y atienden solicitudes de clientes. La configuración del broker dicta el rendimiento, la utilización de recursos y la tolerancia a fallos.
Temas: Categorías o feeds de mensajes que se publican.
Particiones: Los temas se dividen en una o más particiones, lo que permite el paralelismo en el procesamiento y almacenamiento.
Replicación: El proceso de copiar particiones a través de múltiples brokers para garantizar la durabilidad y disponibilidad de los datos en caso de fallas del broker.
Grupos de Consumidores: Un grupo de consumidores que cooperan para consumir mensajes de un tema. Kafka asegura que cada mensaje dentro de un tema se entregue como máximo a un consumidor dentro de cada grupo de consumidores.

Estrategias de Temas y Particionamiento

La configuración efectiva de temas y particiones es fundamental para la escalabilidad y el rendimiento de Kafka.

Número de Particiones

Elegir el número correcto de particiones es una decisión crítica. Más particiones permiten un mayor paralelismo en el lado del consumidor, lo que significa que más instancias de consumidores pueden procesar datos simultáneamente. Sin embargo, demasiadas particiones pueden sobrecargar los recursos del broker (memoria, E/S de disco) y aumentar la latencia. Una regla general común es comenzar con un número de particiones que refleje el rendimiento máximo esperado del consumidor, considerando que es posible que desee agregar más particiones más adelante si es necesario.

Consideración: El número máximo de particiones que un broker puede manejar está limitado por su memoria. Cada partición requiere memoria para sus réplicas líder y seguidora.
Recomendación: Apunte a un número de particiones que se alinee con sus necesidades de paralelismo del consumidor, pero evite la partición excesiva. Monitoree la utilización de recursos del broker para encontrar un equilibrio óptimo.

Clave de Particionamiento

Al producir mensajes, una clave de particionamiento (a menudo una clave de registro) determina en qué partición se escribirá un mensaje. El particionamiento consistente es esencial para el procesamiento ordenado dentro de un grupo de consumidores.

partitioner.class: Esta configuración del productor se puede establecer en org.apache.kafka.clients.producer.internals.DefaultPartitioner (predeterminado, usa el hash de la clave) o un particionador personalizado.
Mejor Práctica: Use una clave que distribuya los mensajes de manera uniforme entre las particiones. Si los mensajes con la misma clave deben procesarse en orden, Kafka garantiza el orden solo dentro de una partición.

Replicación y Tolerancia a Fallos

La replicación es el mecanismo principal de Kafka para garantizar la durabilidad y disponibilidad de los datos.

Factor de Replicación

El factor de replicación determina cuántas copias de cada partición se mantienen en todo el clúster. Para entornos de producción, se recomienda encarecidamente un factor de replicación mínimo de 3.

Beneficio: Con un factor de replicación de 3, Kafka generalmente puede tolerar una falla del broker mientras mantiene otra réplica disponible. La disponibilidad exacta depende de min.insync.replicas, los acks del productor, la configuración de la elección del líder y qué brokers fallan.
Configuración: Esto se establece a nivel de tema, ya sea durante la creación del tema o mediante comandos de kafka-topics.sh.

# Ejemplo: Crear un tema con factor de replicación 3
kafka-topics.sh --create --topic my-production-topic --bootstrap-server kafka-broker-1:9092 --replication-factor 3 --partitions 6

`min.insync.replicas`

Esta configuración del broker dicta el número mínimo de réplicas que deben confirmar una operación de escritura antes de que se considere exitosa. Para temas con un factor de replicación de N, establecer min.insync.replicas=M (donde M < N) asegura que una escritura se confirme solo después de que M réplicas la hayan confirmado. Para evitar la pérdida de datos, min.insync.replicas generalmente debe establecerse en N-1 o N/2 + 1 dependiendo de sus compensaciones de disponibilidad y durabilidad.

Recomendación: Para temas críticos, establezca min.insync.replicas en replication_factor - 1. Esto asegura que al menos dos réplicas (en una configuración de 3 réplicas) tengan los datos antes de confirmar la escritura, evitando pérdidas si el líder falla.
Configuración: Esta es una configuración a nivel de broker y también se puede establecer por tema.

# broker.properties
min.insync.replicas=2

# Configuración a nivel de tema (anula la configuración del broker)
# kafka-configs.sh --alter --topic my-critical-topic --bootstrap-server ... --add-config min.insync.replicas=2

Elección del Líder y Controlador

Kafka utiliza un broker controlador para gestionar el estado del clúster, incluido el liderazgo de las particiones. Las configuraciones robustas del controlador son vitales.

controller.quorum.voters: En clústeres basados en KRaft, esto especifica los votantes del quórum del controlador. Los clústeres basados en ZooKeeper utilizan una configuración de plano de control diferente, por lo que no copie esta configuración ciegamente entre arquitecturas.
num.io.threads y num.network.threads: Estas configuraciones del broker controlan el número de hilos dedicados a manejar solicitudes de E/S y red. Ajústelos según la carga de trabajo y la CPU disponible.

Configuraciones de Productores y Consumidores

Optimizar la configuración de productores y consumidores es clave para lograr un alto rendimiento y baja latencia.

Configuraciones del Productor

acks: Controla el número de confirmaciones requeridas de las réplicas. Establecer acks=all (o -1) proporciona la garantía de durabilidad más fuerte. Combinado con min.insync.replicas, esto es crucial para la producción.
retries: Establézcalo en un valor alto (por ejemplo, Integer.MAX_VALUE) para asegurarse de que las fallas transitorias no provoquen pérdida de mensajes. Use max.in.flight.requests.per.connection de manera efectiva con reintentos.
max.in.flight.requests.per.connection: Controla el número máximo de solicitudes no confirmadas que se pueden enviar a un broker. Los clientes más antiguos a menudo usaban 1 para evitar el reordenamiento con reintentos. Los productores idempotentes modernos pueden preservar el orden con límites seguros más altos, pero verifique la versión de su cliente y la configuración.
batch.size y linger.ms: Estas configuraciones controlan el agrupamiento de mensajes. Los lotes más grandes pueden mejorar el rendimiento pero aumentan la latencia. linger.ms agrega un pequeño retraso para permitir que más mensajes se agrupen.

# producer.properties
acks=all
retries=2147483647
max.in.flight.requests.per.connection=1
batch.size=16384
linger.ms=5

Configuraciones del Consumidor

auto.offset.reset: Para producción, a menudo se prefiere latest para evitar reprocesar mensajes antiguos al reiniciar. earliest se puede usar si necesita reprocesar mensajes desde el principio.
enable.auto.commit: Establézcalo en false para un procesamiento confiable. Las confirmaciones manuales le brindan control sobre cuándo se confirman los offsets, evitando la reentrega o pérdida de mensajes. Use commitSync() o commitAsync() para confirmaciones explícitas.
max.poll.records: Controla el número máximo de registros devueltos en una sola llamada poll(). Ajústelo para gestionar la carga de procesamiento y evitar rebalances del consumidor.
isolation.level: Establézcalo en read_committed cuando use transacciones de Kafka para asegurarse de que los consumidores solo lean mensajes confirmados.

# consumer.properties
group.id=my-consumer-group
auto.offset.reset=latest
enable.auto.commit=false
isolation.level=read_committed
max.poll.records=500

Consideraciones de Seguridad

Asegurar su clúster de Kafka no es negociable en entornos de producción.

Autenticación y Autorización

SSL/TLS: Cifre la comunicación entre clientes y brokers, y entre los propios brokers. Esto requiere generar y distribuir certificados.
SASL (Capa de Autenticación y Seguridad Simple): Use mecanismos SASL como GSSAPI (Kerberos), PLAIN o SCRAM para autenticar clientes.
Autorización (ACL): Configure Listas de Control de Acceso (ACL) para definir qué usuarios o principales pueden realizar operaciones específicas (leer, escribir, crear tema, etc.) en qué recursos (temas, grupos de consumidores).

Cifrado

ssl.enabled.protocols: Asegúrese de usar protocolos seguros como TLSv1.2 o TLSv1.3.
ssl.cipher.suites: Configure conjuntos de cifrado sólidos.

Ejemplo de Configuración (Productor con SASL sobre TLS)

security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="myuser" password="mypassword";
ssl.truststore.location=/path/to/truststore.jks
ssl.truststore.password=password

Ajuste de Rendimiento y Monitoreo

El monitoreo y ajuste continuos son esenciales para mantener un rendimiento óptimo.

Ajuste del Broker

num.partitions: Si bien esta es una configuración a nivel de tema, el broker debe manejar el número total de particiones. Monitoree la CPU, la memoria y la E/S de disco.
log.segment.bytes y log.roll.hours: Controlan el tamaño y la frecuencia de rotación de los segmentos de registro. Los segmentos más pequeños pueden provocar más descriptores de archivos abiertos y una mayor sobrecarga. Los segmentos más grandes pueden consumir más espacio en disco por segmento pero reducen la sobrecarga.
message.max.bytes: El tamaño máximo de un mensaje en bytes. Asegúrese de que sea lo suficientemente grande para su caso de uso, pero no excesivamente.
replica.fetch.max.bytes: Controla el número máximo de bytes por solicitud de recuperación de una réplica seguidora. Ajústelo para equilibrar la eficiencia de la recuperación y el uso de la memoria.

Ajuste de JVM

Tamaño del Heap: Asigne suficiente memoria heap para la JVM que ejecuta Kafka. Monitoree el uso del heap y la actividad del GC.
Recolector de Basura: Elija un algoritmo de GC apropiado (por ejemplo, G1GC a menudo se recomienda para Kafka).

Monitoreo

Implemente un monitoreo integral utilizando herramientas como Prometheus/Grafana, Datadog o soluciones de monitoreo específicas de Kafka.

Métricas Clave: Monitoree la salud del broker, el rendimiento del tema, el retraso del consumidor, el estado de la replicación, la latencia de las solicitudes y la utilización de recursos (CPU, memoria, disco, red).
Alertas: Configure alertas para condiciones críticas como alto retraso del consumidor, falta de respuesta del broker o agotamiento del espacio en disco.

Rebalances de Grupos de Consumidores

Los rebalances de grupos de consumidores ocurren cuando los consumidores se unen o abandonan un grupo, o cuando se reasignan particiones. Los rebalances frecuentes pueden interrumpir el procesamiento.

session.timeout.ms: Cuánto tiempo espera un broker a que un consumidor envíe un latido antes de considerarlo muerto. Los valores más bajos significan una detección más rápida, pero pueden provocar rebalances prematuros debido a fallas de red.
heartbeat.interval.ms: Con qué frecuencia los consumidores envían latidos. Debe ser significativamente menor que session.timeout.ms.
max.poll.interval.ms: El tiempo máximo entre llamadas de encuesta de un consumidor. Si un consumidor tarda más que esto en procesar mensajes y volver a encuestar, se considerará muerto, lo que provocará un rebalance. Asegúrese de que sus consumidores puedan procesar mensajes dentro de este intervalo.
Consejo: Optimice la lógica de procesamiento del consumidor para completar el trabajo dentro de max.poll.interval.ms y evite rebalances innecesarios debido a consumidores lentos.

Valores Predeterminados de Producción que Decidiría Explícitamente

No deje el comportamiento importante de Kafka a valores predeterminados accidentales. Algunos valores predeterminados son razonables para uso general, pero los sistemas de producción necesitan decisiones que coincidan con los datos.

Para flujos de eventos críticos, use un factor de replicación de 3 o más donde el clúster tenga suficientes brokers y racks para soportarlo. Combínelo con acks=all en los productores y min.insync.replicas=2 en un tema de tres réplicas. Esta combinación significa que una escritura solo se confirma cuando el líder y al menos un seguidor en sincronía la tienen. Si demasiadas réplicas se desincronizan, los productores reciben errores en lugar de aceptar silenciosamente una durabilidad más débil.

Esa compensación es intencional. Durante una falla, un tema altamente duradero puede rechazar escrituras en lugar de confirmar datos que solo están en un broker. Algunos sistemas prefieren la disponibilidad sobre la durabilidad para ciertos datos de telemetría o clics. Eso está bien si es una elección consciente. Es peligroso cuando nadie se da cuenta de que el tema estaba configurado de esa manera.

Deshabilite la elección de líder no limpia para temas donde la pérdida de datos no sea aceptable. La elección no limpia puede poner una partición en línea al elegir una réplica fuera de sincronía, pero esa réplica puede carecer de registros confirmados dependiendo del historial de fallas y la configuración del productor. Para datos críticos, permanecer no disponible a menudo es mejor que perder o retroceder registros sin previo aviso.

Número de Particiones: Elija para Rendimiento y Operaciones

El número de particiones controla el paralelismo, pero más particiones no son gratuitas. Cada partición agrega metadatos, descriptores de archivos, trabajo de replicación, trabajo de elección de líder y sobrecarga de recuperación. También afecta el comportamiento del grupo de consumidores. Un tema con 200 particiones puede soportar más paralelismo de consumidores que un tema con 12, pero también crea más piezas móviles durante los reinicios del broker y los rebalances.

Comience estimando el paralelismo y el rendimiento del consumidor. Si el servicio consumidor ejecutará como máximo 12 instancias, 48 particiones pueden ser suficientes. Si espera cientos de hilos de procesamiento independientes, es posible que necesite más. Deje espacio para el crecimiento, porque aumentar las particiones más adelante puede cambiar la distribución de claves y el comportamiento de ordenamiento para mensajes con clave.

El ordenamiento solo está garantizado dentro de una partición. Si todos los eventos para customer_id=123 deben procesarse en orden, use una clave estable basada en ese ID de cliente. No espere ordenamiento en todo el tema. También vigile las claves calientes. Si un cliente, inquilino o dispositivo produce una gran parte del tráfico, el particionamiento basado en claves puede sobrecargar una partición mientras otras permanecen inactivas.

Para sistemas multiinquilino, considere si un tema compartido o muchos temas de inquilinos son más fáciles de operar. Muchos temas pequeños pueden crear sobrecarga de metadatos. Un tema compartido enorme puede complicar la retención, el control de acceso y la respuesta a incidentes. La mejor elección depende de los requisitos de aislamiento y la forma del tráfico.

La Retención es una Decisión de Producto, No Solo una Configuración del Broker

La retención de Kafka determina cuánto tiempo los datos permanecen disponibles para su reproducción. Una retención corta ahorra disco pero limita la recuperación. Una retención larga permite rellenos y flujos de trabajo de auditoría, pero aumenta el costo de almacenamiento y el tiempo de recuperación.

Establezca la retención por tema según cómo se usan los datos. Un tema de comandos podría necesitar solo una ventana corta. Un tema de historial de eventos puede necesitar días o semanas. Un tema compactado que representa el estado más reciente usa un modelo diferente: Kafka mantiene el valor más reciente por clave después de la compactación, más marcadores de eliminación hasta la limpieza.

Las configuraciones comunes incluyen:

retention.ms=604800000
retention.bytes=-1
cleanup.policy=delete

Para temas compactados:

cleanup.policy=compact
min.cleanable.dirty.ratio=0.5
delete.retention.ms=86400000

Tenga cuidado con los mensajes grandes. Kafka puede manejar registros más grandes cuando se configura de manera consistente, pero aumentar message.max.bytes implica verificar max.request.size del productor, fetch.max.bytes del consumidor, la configuración de recuperación de réplicas del broker y el impacto en la memoria. En muchos sistemas, almacenar cargas útiles grandes en almacenamiento de objetos y enviar una referencia a través de Kafka es más simple y confiable.

Configuraciones del Productor que Evitan el Dolor

Para la mayoría de los productores de producción, habilite la idempotencia a menos que tenga una razón específica para no hacerlo. La producción idempotente ayuda a prevenir escrituras duplicadas causadas por reintentos después de fallas transitorias. Muchos clientes modernos de Kafka lo habilitan automáticamente bajo ciertas configuraciones, pero vale la pena hacer visible la decisión en su configuración de productor.

Ejemplo de línea base del productor:

acks=all
enable.idempotence=true
retries=2147483647
delivery.timeout.ms=120000
request.timeout.ms=30000
linger.ms=5
batch.size=32768
compression.type=zstd

La elección de compresión depende del presupuesto de CPU y la versión de Kafka. zstd a menudo proporciona una compresión fuerte, mientras que lz4 y snappy son opciones comunes de baja latencia. Pruebe con sus cargas útiles. Los registros JSON, los registros Avro, los mensajes protobuf y los datos binarios ya comprimidos se comportan de manera diferente.

El agrupamiento es otra compensación. Un linger.ms pequeño le da al productor una ventana corta para agrupar registros, lo que puede mejorar el rendimiento y la compresión. Configurarlo demasiado alto agrega latencia. Para las rutas de solicitud orientadas al usuario, tenga en cuenta los presupuestos de latencia. Para la ingesta en segundo plano, un poco más de retardo puede ser aceptable.

No ignore los errores del productor. Si acks=all y min.insync.replicas rechazan una escritura durante problemas del broker, eso es una contrapresión útil. La aplicación debe decidir si reintentar, almacenar en búfer, fallar la solicitud o enrutar a una alternativa. Registrar el error y descartar el evento no es una estrategia de durabilidad.

Configuraciones del Consumidor que Coinciden con la Semántica de Procesamiento

Las confirmaciones de offset del consumidor definen lo que significa "procesado". Con enable.auto.commit=true, el cliente puede confirmar offsets antes de que su aplicación haya completado el trabajo de manera segura. Eso puede ser aceptable para análisis desechables, pero es arriesgado para pagos, pedidos, implementaciones o cualquier cosa donde perder un evento duele.

Para un procesamiento confiable, deshabilite la confirmación automática y confirme después de que el trabajo esté hecho:

enable.auto.commit=false
max.poll.records=500
max.poll.interval.ms=300000
session.timeout.ms=45000
heartbeat.interval.ms=15000
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

La estrategia de confirmación depende de la aplicación. commitSync() es más simple y da un comportamiento de falla claro, pero puede agregar latencia. commitAsync() puede mejorar el rendimiento, pero debe manejar las fallas de devolución de llamada con cuidado. Muchos servicios confirman periódicamente después de lotes exitosos y hacen que las escrituras posteriores sean idempotentes para que la reproducción sea segura.

Si procesar un mensaje puede llevar mucho tiempo, reduzca max.poll.records, aumente max.poll.interval.ms o mueva el trabajo lento detrás de una cola interna mientras el bucle de encuesta continúa de manera responsable. Un consumidor que deja de encuestar durante demasiado tiempo provoca un rebalance, y los rebalances repetidos hacen que todo el grupo parezca inestable.

Use membresía estática para consumidores que se reinician con frecuencia pero vuelven con identidades estables. Puede reducir los rebalances innecesarios durante implementaciones continuas. El reequilibrio cooperativo también puede reducir la interrupción en comparación con el reequilibrio ansioso, dependiendo del soporte del cliente.

Seguridad que los Equipos Pueden Operar

Kafka de producción debe usar cifrado en tránsito cuando el tráfico cruza redes no confiables o transporta datos confidenciales. La mayoría de las organizaciones deben usar TLS para la comunicación cliente-broker y la comunicación entre brokers. La autenticación puede ser TLS mutuo, SASL/SCRAM, Kerberos, OAuth u otro mecanismo compatible según el entorno.

Las ACL deben ser lo suficientemente específicas para evitar daños accidentales. Un productor para orders.created no necesita permiso para escribir en cada tema. Un grupo de consumidores para facturación no necesita permiso para alterar las configuraciones del broker. Use convenciones de nomenclatura que hagan que las ACL sean legibles y mantenga las principales de servicio vinculadas a las aplicaciones en lugar de a humanos individuales.

Los secretos necesitan rotación. Si las credenciales SASL o los almacenes de claves se copian manualmente en los servidores, la rotación se vuelve dolorosa y eventualmente deja de suceder. Use el administrador de secretos de su plataforma cuando sea posible. Pruebe la rotación en el entorno de prueba, incluidos los reinicios continuos de clientes.

También decida quién puede crear temas. La creación automática de temas es conveniente en desarrollo y peligrosa en producción. Un error tipográfico en un nombre de tema puede crear un nuevo tema con particiones predeterminadas, replicación predeterminada y retención predeterminada. Muchos clústeres de producción deshabilitan la creación automática de temas y gestionan los temas a través de código de infraestructura o un flujo de trabajo aprobado.

Verificaciones del Broker y Almacenamiento

Kafka es sensible al disco. Use almacenamiento con latencia predecible, monitoree el uso del disco de manera agresiva y mantenga suficiente espacio libre para retención, recuperación de replicación y errores operativos. Un broker con un disco lleno puede crear un incidente mucho mayor que un broker con CPU alta.

Separe los registros de Kafka de cargas de trabajo ruidosas no relacionadas. Evite colocar datos de Kafka en discos compartidos donde otro proceso pueda consumir repentinamente E/S. En entornos de nube, comprenda los límites de rendimiento del volumen, los créditos de ráfaga y el comportamiento de recuperación. Un disco que funciona bien durante un minuto aún puede tener dificultades bajo replicación y compactación sostenidas.

La conciencia de rack es importante cuando tiene múltiples zonas de disponibilidad o racks. Configure los ID de rack del broker y la ubicación del tema para que las réplicas no estén todas en el mismo dominio de falla. Un factor de replicación de 3 es menos útil si las tres réplicas desaparecen con un problema de rack o zona.

Monitoreo y Alertas que Capturan Fallas Reales

Una configuración de monitoreo útil de Kafka observa tanto los internos de Kafka como la experiencia del cliente. Las métricas del broker por sí solas no le dicen si los consumidores se están manteniendo al día o si los productores están viendo errores.

Vigile las particiones subreplicadas, las particiones fuera de línea, el recuento de controladores activos, la latencia de las solicitudes, las tasas de error de producción y recuperación, el rendimiento de la red, el uso del disco, la latencia de E/S del disco, las tasas de expansión y contracción de ISR, el tiempo de cola de eventos del controlador, el retraso del consumidor, la tasa de rebalance y los recuentos de reintentos/errores del cliente.

El retraso del consumidor necesita contexto. Un retraso de 100 registros puede estar bien en un tema que recibe millones por hora. Un retraso de 100 puede ser grave en un tema de comandos de bajo volumen. Alerte sobre la edad del retraso o el tiempo de recuperación cuando pueda, no solo el recuento bruto de registros.

Pruebe los reinicios del broker durante las ventanas de mantenimiento antes de la primera falla real. Un clúster de Kafka de producción debería sobrevivir a un reinicio planificado del broker sin pérdida de datos y sin sorprender a los clientes. Si un reinicio del broker crea un incidente importante, el clúster ya era frágil.

Una Verificación de Preparación para Producción

Antes de considerar que un clúster de Kafka está listo para producción, verificaría estos elementos:

Los temas críticos tienen particiones explícitas, factor de replicación, retención, política de limpieza y min.insync.replicas.
Los productores para temas críticos usan acks=all, idempotencia donde sea compatible, reintentos y manejo de errores claro.
Los consumidores confirman offsets solo después de que la aplicación haya alcanzado su punto de procesamiento previsto.
TLS, autenticación y ACL están habilitados y probados.
La creación automática de temas está deshabilitada o estrictamente controlada.
El monitoreo cubre la salud del broker, los errores del cliente, el retraso del consumidor, el disco y la replicación.
Las expectativas de copia de seguridad o reproducción están documentadas. La retención de Kafka no es un sustituto para cada necesidad de copia de seguridad.
Se han probado los procedimientos de reinicio del broker, implementación del cliente y rotación de credenciales.

La Conclusión Práctica

La configuración de producción de Kafka es un conjunto de compensaciones, no una receta universal. Haga explícitas las decisiones de durabilidad, ordenamiento, reproducción, seguridad y latencia por tema y por aplicación. Luego pruebe esas elecciones con reinicios del broker, fallas del cliente, consumidores lentos y escenarios de disco lleno antes de que el tráfico de producción le enseñe la lección.