Plataformas & Sistemas Distribuidos
Cuando un producto crece, el problema deja de ser una función y pasa a ser cómo hablan entre sí los servicios. Ahí entran los límites entre servicios, el reparto de eventos y los flujos que no se pueden perder por el camino.
El síntoma suele ser el mismo: dos equipos ya no pueden desplegar sin coordinarse, un proceso de varios pasos se queda a medias y nadie sabe dónde, o el mismo dato cuenta cosas distintas según a qué servicio le preguntes.
Partir un monolito no es la solución por defecto. Primero se busca dónde están de verdad los límites del negocio, y solo entonces se separa lo que haga falta, con los eventos y los contratos que eso exige.
Frentes de trabajo
Dónde cortar
Un microservicio mal cortado es peor que el monolito del que salió: mismo acoplamiento, más latencia y más despliegues. Antes de partir nada se dibuja qué datos escribe cada parte del negocio, y el corte va por ahí, no por capas técnicas.
Eventos que se pueden reprocesar
Un evento es un contrato con futuro: alguien lo va a leer dentro de un año y puede que haya que reprocesar los de la semana pasada. Por eso van con esquema versionado, clave de partición pensada y consumidores idempotentes.
Procesos que no se pierden
Un alta, un cobro o una conciliación son varios pasos con esperas y fallos por el medio. Con Temporal el estado del proceso vive fuera del servicio, así que un despliegue o una caída no dejan a nadie a mitad de camino, y se puede ver en qué paso está cada caso.
Multitenant de verdad
Aislar clientes no es solo filtrar por tenant_id. Es decidir qué se comparte y qué no en datos, configuración, límites de uso y despliegue, y dejarlo en un sitio donde no se pueda olvidar al escribir el siguiente endpoint.
Cómo encaja
Un evento, de punta a punta
El orden importa: si el evento se publica antes de confirmar la escritura, algún día se publica algo que nunca ocurrió.
Servicio A
Outbox
Kafka
Servicio B
Escribe el cambio y el evento en la misma transacción
Un publicador lee la tabla y publica, al menos una vez
Consume su partición, en orden por clave
Si ya procesó ese id, lo descarta
Confirma el offset solo cuando terminó
Un workflow que puede fallar a mitad
Reservar, cobrar y confirmar son tres pasos con tres dueños distintos. Temporal guarda en qué punto se quedó, así que un reinicio no borra el avance.
Programado
Alguien lo dispara y queda registrado con su id de negocio.
En curso
Cada paso es una actividad con timeout propio.
Esperando reintento
El proveedor respondió mal o no respondió. Se espera y se vuelve a intentar.
Completado
El resultado queda escrito una sola vez, aunque el paso se repitiera.
Compensado
Si no hay manera, se deshace lo hecho y el caso queda cerrado, no colgado.
Los reintentos son parte del diseño, no una excepción: backoff, tope de intentos y, al final, una compensación explícita.
Qué incluye
- Diseño de microservicios: dónde cortar, qué datos son de quién y qué contrato hay entre ellos.
- Arquitectura orientada a eventos con Kafka: topics, particiones, schemas y compatibilidad hacia atrás.
- Workflows durables con Temporal para procesos de varios pasos que deben sobrevivir a un reinicio.
- Comunicación entre servicios con gRPC y Protobuf cuando la latencia importa, y REST cuando no.
- Patrones de consistencia: saga, outbox transaccional, idempotencia y reintentos con backoff.
- Diseño multitenant: aislamiento de datos, configuración y despliegue por cliente.
- API gateway y BFF para que cada cliente reciba lo que necesita sin acoplarse a todos los servicios.
- Analítica sobre OLAP (ClickHouse) separada de la base transaccional.
- Estrategia de migración: extraer un servicio a la vez sin congelar el producto.
Cómo avanza el proyecto
- 01El flujo actual se dibuja con tu equipo, marcando dónde se pierden datos hoy.
- 02Los límites de servicio y los eventos, con sus esquemas, quedan definidos antes de mover una línea de código.
- 03Se migra un flujo completo de punta a punta antes de tocar el resto, para que el riesgo se vea en pequeño.
- 04El sistema queda observable: qué se encoló, qué se reintentó y qué falló.
Qué te llevas
- Los flujos migrados, con sus esquemas de evento versionados.
- Mapa de servicios y de quién es dueño de cada dato.
- Paneles para ver el estado de las colas y de los workflows.
- Documento de decisiones: qué se eligió y por qué.
Stack habitual
- Mensajería
- Apache KafkaRabbitMQRedis StreamsPub/Sub
- Orquestación
- TemporalApache AirflowSidekiqCelery
- Contratos
- gRPCProtobufOpenAPIJSON Schema
- Servicios
- PythonNestJSRuby on RailsGo
- Datos
- PostgreSQLClickHouseRedisDynamoDB
- Patrones
- SagaOutboxIdempotencyEvent sourcingCQRS
Dónde se ha hecho esto
Preguntas frecuentes
¿Hay que partir el monolito?
Casi nunca del todo, y nunca de entrada. Un microservicio mal cortado es peor que el monolito del que salió. Lo primero es ver qué datos escribe cada parte del negocio; a veces la respuesta es extraer dos servicios y dejar el resto donde está.
¿Cómo se migra sin congelar el producto?
Migrando un flujo completo de punta a punta antes de tocar el resto. Así el riesgo se ve en pequeño, el equipo aprende el patrón con un caso real y el producto sigue entregando mientras tanto.
¿Hace falta Kafka o basta con una cola?
Depende de si hay que releer el pasado. Una cola reparte trabajo y lo olvida; Kafka guarda el historial, así que un consumidor nuevo puede reprocesar lo de la semana pasada. Si nadie va a reprocesar nada, una cola normal es más barata de operar.
¿Cuándo conviene un workflow durable en vez de una cola?
Cuando el proceso tiene varios pasos con esperas y dueños distintos: un alta, un cobro, una conciliación. Con Temporal el estado vive fuera del servicio, así que un despliegue o una caída no dejan casos a medias y se puede ver en qué paso está cada uno.