Claves
- Aislar el recorrido que cobra el dinero de todo lo demás.
- Usar eventos para el trabajo que no tiene que terminar antes de responder al cliente.
- Cada servicio es dueño de sus datos; se comparten mediante eventos, no tablas comunes.
- En cuanto las peticiones cruzan servicios, el trazado distribuido es imprescindible.
Cuando pedidos, pagos, menús y despacho comparten una aplicación, un componente lento puede bloquear el pago. Cómo el diseño orientado a eventos aísla los fallos, y lo que cuesta.
El problema de los picos
La demanda de reparto de comida llega en picos bruscos en torno a las comidas. En una sola aplicación, la búsqueda en menús, las recomendaciones, el despacho y el pago compiten por los mismos hilos, conexiones y memoria. Una consulta lenta en una zona puede agotar los recursos que necesita el pago.
Proteger el recorrido que cobra
El primer principio de diseño era sencillo: pedidos y pagos deben seguir funcionando aunque todo lo demás esté degradado. Por eso se separaron en servicios propios con sus propios almacenes de datos, y cualquier otra interacción con ellos se hizo asíncrona.
Eventos para todo lo que puede esperar
Cuando se hace un pedido, el cliente necesita una confirmación inmediata. Avisar al restaurante, asignar un repartidor y actualizar la analítica puede ocurrir un momento después. Un evento «pedido realizado» publicado en Kafka permite que cada consumidor trabaje a su ritmo, y que falle sin afectar al pedido.
- Servicio de pedidos: acepta el pedido y publica un evento.
- Servicio de restaurantes: consume el evento y actualiza la pantalla de cocina.
- Servicio de despacho: consume el evento y asigna un repartidor.
- Servicio de notificaciones: informa al cliente a medida que llegan los eventos de estado.
Cada servicio es dueño de sus datos
Pedidos y pagos necesitan transacciones, así que viven en PostgreSQL. Los menús son documentos cuya forma varía de un restaurante a otro, así que viven en MongoDB. Los servicios nunca leen las tablas de otros; mantienen actualizados los datos que necesitan mediante eventos.
Lo que cuesta
Los sistemas orientados a eventos son más difíciles de entender que una sola aplicación. Los datos son consistentes a la larga, los fallos pueden ocurrir entre servicios y depurar significa seguir una petición a través de varios procesos. El trazado distribuido, aquí con Zipkin, y los consumidores idempotentes son la inversión mínima para que esta arquitectura sea manejable.
Para una pequeña herramienta interna sería sobreingeniería. Para una plataforma cuyos ingresos dependen de que el pago funcione en hora punta, es el equilibrio adecuado.
¿Le ha gustado? Reciba el próximo por correo.