¡Hola!
Resumen de este email:
- Por qué no usar la base de datos para hacer un Event Bus. (+ publicado en Codely Pro)
⏱️ Tiempo estimado de lectura: Un poquito y ya (hay salseito).
❌ Por qué no usar la base de datos para hacer un Event Bus
Hace un par de semanas publicamos un post en LinkedIn comentando Por qué no usar RabbitMQ o Kafka para hacer un Event Bus y no nos imaginamos el debate que se iba a generar por ello.
Así que aprovechamos la newsletter de hoy para responder a algunos de esos puntos dando nuestra opinión.
🔥 Esta estructura únicamente sirve si tienes un único worker consumiendo
Esta es fácil de responder: Se pueden tener múltiples workers consumiendo.
La único a tener en cuenta es hacer un SELECT FOR UPDATE para bloquear las rows y que no procesemos por duplicado los mensajes.
Esto nos lleva a la siguiente:
🔐 Gestión de locks y dead locks
Pensando en una base de datos, este es EL TEMA. Puede pasar que si tenemos más de un worker/consumidor haciendo SELECT FOR UPDATE de la misma tabla acabemos teniendo estos problemas.
Y si alguna vez has estado de guardia, que te despierte una alerta a las 4am por dead locks es de las peores cosas que hay.
Por suerte la mayoría de bases de datos modernas tienen sistemas para sólo bloquear las rows que se han devuelto en lugar de toda la tabla. Si acompañamos eso con un timeout para los locks en esas queries, podemos evitar este gran problema.
⏱️ Yo para dedicar horas en implementar está solución prefiero ir directamente a dedicarlas con la pieza que toca
Este es un pensamiento totalmente válido y que puede tener sentido dependiendo del contexto.
Si ya tenemos un event bus en memoria y queremos implementar uno asíncrono, seguramente en nuestro stack ya tengamos una base de datos y no un sistema de mensajería.
Si es así, tiene pinta que sería más sencillo y rápido hacerlo en la propia base de datos. Si somos una empresa con una carga gigante y vemos que la base de datos se va a quedar corta para este tipo de operaciones, entonces sí que tiene sentido ir directamente a "la pieza que toca".
🔔 Puede sonar muy bonito y pero cuando las cargas pasan de cierto umbral no sirve
Toda la razón. La propuesta de hacer el event bus en la base de datos no es para tener una gran escala, es para tener un punto intermedio entre "no tengo event bus" y "me monto un Kafka".
El event bus en base de datos puede escalar fácilmente a decenas de miles de eventos por segundo. Esto seguramente es más que suficiente para la mayoría de proyectos. Si tenemos requisitos superiores a estos, allí es el momento de pasarnos a otro sistema. Pero hasta ese momento podemos postponer la decisión.
Todo esto es lo que explicamos en el curso de Event bus en base de datos. Haz un event bus escalable hasta que necesites migrar a otro sistema.
Queremos aprovechar esta newsletter para daros las GRACIAS por la comunidad que tenemos.
Tener estas respuestas y que se abra debate de esta forma nos llena de vida. Cuestionarnos las cosas que tenemos asentadas es la mejor forma de poder mejorar. Gracias, de verdad.
Y ya que has llegado hasta esta parte de la newsletter, te dejamos aquí el chiste de la semana, qué sé que lo estabas esperando:
> ¿Por qué el administrador de base de datos dejó a su pareja? Porque tenía una relación one-to-many 😂 😂 😂
¡Un saludo!