¡Hola!
Resumen de este email:
- Los patrones Inbox y Outbox pueden ser sobreingeniería (+ curso publicado en Codely Pro)
⏱️ Tiempo estimado de lectura: 1 minutito.
📬 Los patrones Inbox y Outbox pueden ser sobreingeniería
Los patrones inbox y outbox son dos patrones que nos aseguran que un mensaje se ha entregado o enviado. Para analizarlos vamos a imaginar el caso de uso de registrar un usuario:
📤 El Outbox pattern
El outbox pattern es el patrón que se encarga de que un mensaje siempre sea entregado.
Una vez un usuario se ha registrado (insert en base de datos) queremos publicar el evento de usuario registrado (en RabbitMQ, por ejemplo).
Pero algo que puede pasar, es que el Rabbit se caiga. En ese momento podemos elegir:
- 💥 Hacer rollback del caso del insert de usuario y devolver un error 500.
- 🥺 Asumir que hemos perdido el evento.
- 📤 Aplicar el patrón outbox.
Obviamente las 2 primeras no nos gustan, así que podemos optar por la 3a. Eso implica que en lugar de publicar en el RabbitMQ en ese momento, haremos un insert del evento en una tabla nuestra.
Luego tendremos otro proceso que leerá de esa tabla y publicará en el Rabbit. De esta forma nos aseguramos de que siempre funcionen bien los casos de uso.
📤 El Inbox pattern
El inbox pattern es el patrón que se encarga de que un mensaje siempre sea leído.
En un suscriptor podemos escuchar el evento de usuario registrado para enviarle un email de bienvenida.
Pero algo que puede pasar es que el servicio de envío de email esté caído y que por culpa de eso perdamos ese evento o que se sature la cola y se acabe cayendo el Rabbit por ello.
Si aplicamos el inbox pattern, lo que haremos es una vez consumido el mensaje guardarlo en una tabla de nuestra base de datos. De esta forma, si se encolan muchos, lo que se llena es nuestra base de datos en lugar de el Rabbit.
Luego tendremos un proceso que leerá de esa tabla y ejecutará el suscriptor pertinente.
Estos 2 patrones son muy poderosos ya que nos desacoplan del sistema de mensajería (también nos pueden permitir desacoplarnos de servicios de envío de email, notificaciones…). Además, el patrón inbox nos puede ayudar a evitar consumir mensajes duplicados.
Por otro lado, añadir "por si acaso" estos sistemas que acabamos de explicar, puede causar diversos problemas. Hemos añadido nuevos niveles de indirección, movido cargas a otro sistema (del Rabbit a la BD), añadido nuevos procesos para consumir de estas tablas… Sobreingeniería de libro.
Todo esto lo explicamos en el curso que acabamos de publicar sobre estos patrones. Ya disponible para Codely Pro Premium. 😊
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 God Object está deprimido? Porque le han dado demasiadas responsabilidades. 😂 😂 😂 Chiste enviado por Esti Alvarez, ¡Mil gracias! 😊 - Si nos quieres enviar tu chiste tech publica un post en Twitter mencionándonos.
¡Un saludo!