Spring GDS 25 Aniversario
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
Una message queue es un buffer que se sitúa entre dos partes de un sistema para que no tengan que hablarse en el mismo momento. Un servicio pone un mensaje en la cola, otro servicio lo saca y lo procesa cuando está listo. El emisor no espera a que el trabajo termine. Entrega el mensaje y sigue a lo suyo.
Esto desacopla tiempos y carga. Si una ráfaga de tráfico produce más trabajo del que los consumidores pueden gestionar, la cola absorbe el atasco en lugar de tumbar el sistema. Los mensajes esperan en fila y se procesan a un ritmo constante. Una plataforma de vídeo que necesita transcodificar cada subida puede dejar cada archivo en una cola, devolver el control al usuario de inmediato y dejar que un grupo de workers digiera la codificación en segundo plano. Herramientas como RabbitMQ, Amazon SQS y las colas sobre Redis son opciones habituales.
Las colas también añaden fiabilidad. Un mensaje permanece en la cola hasta que un consumidor confirma que lo gestionó, así que un worker que se cae a mitad de tarea no pierde el trabajo. Conviene distinguir una cola de un sistema basado en logs como Kafka. Una cola clásica entrega cada mensaje a un consumidor y lo elimina una vez procesado, mientras que un log mantiene un registro ordenado que muchos consumidores pueden reproducir. Herramientas distintas para formas distintas de problema.
Añadimos una message queue cuando un sistema tiene trabajo que no debería bloquear al usuario. Un cliente con una plataforma de alto tráfico tenía el procesado de imágenes, las notificaciones y la generación de informes ocurriendo en línea, y en pico la carga agotaba el tiempo de las peticiones. Sacamos ese trabajo detrás de una cola. La respuesta de cara al usuario cayó a milisegundos, y un conjunto de workers asumió la parte pesada a un ritmo que la infraestructura podía sostener.
Las colas son una pieza central de cómo abordamos la integración de plataformas y la integración API, porque los sistemas que conectamos rara vez van a la misma velocidad. Diseñamos los contratos de los mensajes, el comportamiento de reintento y la gestión de la dead-letter para que un trabajo fallido se capture y se reproduzca, no se pierda en silencio. El resultado son sistemas que se mantienen receptivos bajo carga y siguen funcionando cuando una pieza tiene un mal día.
¿El trabajo se acumula y agota los tiempos bajo carga? Saquémoslo del camino crítico.
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
Convertir una marca en un negocio que funciona.
Medio millón de personas. Una app. Cero caos.















