Principios para Diseñar Microservicios
Ocho decisiones de diseño que separan un sistema que escala de un monolito distribuido.
- Senior consultant y fundador de SR Consulting Group.
- Más de 20 años liderando proyectos, desde startups hasta megaproyectos corporativos; 15+ en dirección ejecutiva de multinacionales.
- Arquitecturas distribuidas, modernización de sistemas legados y adopción de microservicios en entornos de alta criticidad.
- Profesor de Project Management, Dirección Estratégica e IA para la transformación de negocios en Tecnológico de Monterrey y Tecmilenio.
Enfoque de esta sesión
Cada principio viene con un ejemplo real, el error que más veo en las organizaciones y una pregunta para tu propio sistema.
Canasta MX, viernes de Buen Fin, 11:58 p.m. Un cambio de una línea en Promociones… y se cae el checkout de toda la tienda en línea.¿Por qué un error en descuentos detiene las ventas?
Vamos a acompañar a Canasta MX durante su migración: lo que hizo bien y lo que le costó aplicar tarde cada principio.
Caso ilustrativo con fines didácticos, construido con situaciones frecuentes en migraciones reales.
Canasta MX: el monolito que empezó a doler
60 supermercados en el centro del país, venta en línea con entrega el mismo día. Un sistema de 8 años, una sola base de datos y 35 desarrolladores.
- EscalabilidadPara aguantar el catálogo en Buen Fin escalaban todo, incluido el backoffice.
- Equipos35 desarrolladores en el mismo código, esperando turno para integrar.
- DesplieguesUno al mes, domingo de madrugada, con todo el equipo en llamada.
- FallosUn error de memoria en Promociones tumbó el checkout en pleno Buen Fin.
Un microservicio es un componente pequeño, dueño de una capacidad de negocio y de sus datos, que se despliega de forma independiente y colabora con otros a través de contratos por la red.
Cuándo sí y cuándo no: es una decisión de arquitectura, no de moda
Sí conviene cuando…
- Varios equipos chocan en el mismo código y en la misma fecha de liberación.
- Partes del sistema tienen necesidades de escala o de disponibilidad muy distintas.
- El dominio de negocio ya se entiende bien y sus límites son estables.
- Ya existe automatización: CI/CD, contenedores y monitoreo.
No conviene cuando…
- Estás validando un producto nuevo y el modelo de negocio aún cambia cada mes.
- El equipo completo cabe en una sala de juntas.
- Desplegar todavía es un proceso manual de horas.
- La única razón es «porque Netflix lo hace».
El punto medio existe: un monolito modular bien diseñado.Primero ordena los límites dentro de un solo despliegue; extrae servicios cuando duela de verdad.
Al terminar esta sesión podrás…
La migración de Canasta MX: 12 meses, 8 principios
Cada principio llegó a tiempo… o tarde. En rojo, lo que costó aplicarlo tarde.
Haz clic en un principio para ir directo a él. Caso ilustrativo con fines didácticos.
Responsabilidad única a nivel de servicio
Cada servicio es dueño de una sola capacidad de negocio y de las reglas que la gobiernan. Si cambia la regla, cambia un solo servicio.
1El tropiezo
Mes 2Al trazar los primeros límites crearon un servicio «Clientes» con direcciones, preferencias, lealtad y crédito. Pronto, cuatro equipos lo modificaban a la vez.
Cada cambio de lealtad esperaba la fila de otros tres equipos.
2La corrección
Mes 8Lo separaron por capacidad: Identidad, Direcciones y Lealtad. Cuando Marketing cambia las reglas de puntos, solo se toca Lealtad.
Reflexiona
¿Puedes describir tu servicio en una frase sin usar la palabra «y»?
Independencia de despliegue
Un equipo debe poder llevar su servicio a producción sin coordinar fechas, ventanas ni versiones con otros equipos.
1El tropiezo
Mes 3Los servicios compartían la librería «canasta-commons» con los modelos de negocio. Un cambio en Producto obligó a desplegar nueve servicios juntos, en orden, un domingo.
Un monolito distribuido: lo peor de ambos mundos.
2La corrección
Mes 5La librería quedó solo para lo técnico (logs y seguridad) y cada servicio define su propio modelo. Precios publica ofertas varias veces al día sin tocar a nadie.
Reflexiona
¿Cuántos equipos deben ponerse de acuerdo para que un cambio llegue a producción?
Descentralización de datos: una base por servicio
Cada servicio es dueño exclusivo de sus datos. Los demás los consultan por su API o se enteran por eventos; nunca leen sus tablas.
1El tropiezo
Mes 4Para salir rápido, Entregas leía directo las tablas de Órdenes. Cuando Órdenes reorganizó su tabla de direcciones, Entregas dejó de ver las referencias del domicilio.
Un fin de semana de repartidores buscando casas sin referencias.
2La corrección
Mes 6Órdenes publica «OrdenConfirmada» con la dirección completa y Entregas guarda su propia copia. Cada servicio cambia su base sin pedir permiso.
Reflexiona
Si mañana renombras una columna, ¿sabes quién se rompe?
Comunicación a través de APIs bien definidas
Un servicio se conoce solo por su contrato: qué recibe, qué responde y qué eventos publica. Lo de adentro cambia; el contrato, no sin aviso.
1El tropiezo
Mes 5En una refactorización, Pagos cambió el estatus «APROBADO» por «approved». La app no reconoció el valor y mostró «pago rechazado» a cobros que sí pasaron.
Clientes que pagaron dos veces y una semana de reembolsos.
2La corrección
Mes 6Pagos publica su contrato en OpenAPI; la app y Órdenes tienen pruebas de contrato en el pipeline. Si un cambio rompe a un consumidor, no llega a producción.
Reflexiona
¿Tu API documenta lo que promete o solo lo que hace hoy?
Diseño para el fallo
En un sistema distribuido algo siempre está fallando. El diseño decide si la falla se queda en un servicio o tumba a todo el negocio.
1El tropiezo
Mes 6Checkout pedía al PAC timbrar la factura dentro de la compra, sin timeout. Un viernes de quincena el PAC se puso lento y Checkout se quedó esperando.
40 minutos sin ventas, con Pagos funcionando perfecto.
2La corrección
Mes 7Timeout de 2 s, reintentos con espera creciente y circuit breaker. Si el PAC falla, la venta se confirma y la factura se encola para timbrarse después.
Reflexiona
¿Qué hace tu sistema cuando una dependencia tarda 30 segundos en vez de fallar?
Observabilidad desde el diseño
Si no ves qué pasa entre servicios, no puedes operarlos. Logs, métricas y trazas se diseñan con el servicio, no después del primer incidente.
1El tropiezo
Mes 7Cada servicio escribía logs en texto libre, en su propio servidor. En el Hot Sale, rastrear un «mi pedido no avanza» implicaba revisar seis servicios a mano.
Hasta dos días para responder una sola queja.
2La corrección
Mes 9ID de correlación desde la app, tracing distribuido con OpenTelemetry y métricas RED por servicio. Hoy ven en minutos que la reserva en Inventario tardó 9 s.
Reflexiona
¿Cuánto tardarías hoy en saber en qué servicio falló el pedido 48213?
Autonomía de equipos: la Ley de Conway aplicada
Los sistemas copian la estructura de comunicación de quien los diseña. Diseña los equipos que producirán la arquitectura que quieres.
1El tropiezo
Meses 1 a 9Conservaron los equipos por capa: frontend, backend, DBA y operaciones. Cada cambio cruzaba cuatro colas y los servicios volvieron a parecerse al organigrama.
Un cambio de un día en Promociones tardaba tres semanas.
2La corrección
Mes 10Equipos por capacidad: Entregas tiene producto, desarrollo, QA y operación. Decide su backlog, despliega y atiende sus propias alertas.
Reflexiona
¿Tu organigrama se parece a tu arquitectura? ¿Fue a propósito?
Evolución y versionado de APIs
Los contratos cambian. La meta es evolucionarlos sin romper a quien ya los usa: primero cambios compatibles; versión nueva solo si no hay otra opción.
1El tropiezo
Mes 11Catálogo cambió el campo «precio» de pesos a centavos en la misma versión, sin avisar. Las terminales de autocobro mostraron el kilo de aguacate a $4,900.
Autocobro detenido en las 60 tiendas durante una mañana.
2La corrección
Mes 12Para vender por kilo o por pieza crearon /v2 de Catálogo. Convivió seis meses con /v1, se midió quién seguía en v1 y se apagó con fecha anunciada.
Reflexiona
¿Sabes con certeza quién consume tu API hoy?
Caso guiado: rediseña el servicio de Órdenes de Canasta MX
- 1Límites¿Qué decide Órdenes y qué no le toca?Ciclo de vida del pedido y su estado. El stock es de Inventario; el cobro, de Pagos.
- 2Datos¿Qué guarda en su propia base?Pedido, partidas, sustituciones aceptadas, ventana de entrega y precio al momento de comprar.
- 3Comunicación¿Qué debe ser síncrono y qué evento?Reservar y cobrar, síncrono. Envío, factura y avisos reaccionan a «OrdenCreada».
- 4Fallos¿Qué pasa si Pagos no responde?Timeout y orden «pendiente de pago»; si el cobro falla, se libera el stock (saga).
Ejercicio: el backoffice de Canasta MX sigue siendo un monolito. ¿Cómo lo descompondrías?
Agrupa en servicios. Para cada uno, define qué datos son suyos y qué eventos publica.
Pista: ¿qué ya existe del lado digital? ¿Y qué ni siquiera conviene construir?
- 1¿Qué parte de tu sistema desplegarías por separado mañana, si pudieras?
- 2¿Cuál fue la última falla que se propagó de un sistema a otro? ¿Qué principio faltó?
- 3¿Quién es dueño, de punta a punta, del servicio más crítico de tu empresa?
Si ves esto en video: pausa y escribe tu respuesta en una línea.
Lo que Canasta MX ganó… y lo que tuvo que pagar
Complejidad operacional
- Ganó
- Pasar de un despliegue al mes a varios al día.
- Pagó
- Decenas de servicios, pipelines, secretos y alertas que operar.
- Mitigó con
- Una plataforma común: CI/CD, contenedores y plantillas de servicio.
Consistencia eventual
- Ganó
- Que la tienda siga vendiendo aunque Entregas falle.
- Pagó
- Por unos segundos, un pedido se ve «pagado» en la app y «pendiente» en Entregas.
- Mitigó con
- Sagas, operaciones idempotentes y conciliación diaria.
Debugging distribuido
- Ganó
- Fallas aisladas en lugar de caídas totales.
- Pagó
- Una sola queja de un cliente puede cruzar seis servicios.
- Mitigó con
- Tracing distribuido e ID de correlación obligatorios.
Los microservicios no eliminan la complejidad: la mueven del código a la red y a la organización.
¿Estamos resolviendo un problema de negocio o creando complejidad innecesaria?
¿Tenemos la madurez organizacional y técnica para soportarlo?
Lo que Canasta MX haría distinto
- Empezar con un monolito modular.Ordenar los límites dentro de Canasta.war habría evitado el servicio «Clientes».
- Plataforma antes que servicios.Pipelines y tracing desde el mes 1, no desde el mes 9.
- Rediseñar los equipos desde el día uno.La Ley de Conway les cobró nueve meses de colas.
- Estrangular, no reescribir.El backoffice se migra una capacidad a la vez (Strangler Fig), en producción.
Seis ideas, y lo que costó aplicarlas tarde
Una capacidad por servicioUn «Clientes» con cuatro equipos encima.
Despliegue independienteNueve servicios desplegados juntos.
Tus datos son tuyosRepartidores sin referencias.
Contratos explícitosClientes que pagaron dos veces.
Diseña para el fallo40 minutos sin ventas.
Observa desde el día unoDos días para rastrear un pedido.
- Agrega un timeout a una llamada que hoy no lo tiene.
- Identifica una tabla que dos sistemas comparten.
- Escribe el contrato de un endpoint crítico.
Para seguir aprendiendo
- Building Microservices, 2.ª ed.Sam Newman · O’Reilly, 2021
- Monolith to MicroservicesSam Newman · O’Reilly, 2019
- Cloud Design PatternsMicrosoft · Azure Architecture Center
- Release It!, 2.ª ed.Michael Nygard · Pragmatic Bookshelf, 2018
- microservices.ioCatálogo de patrones de Chris Richardson
Contacto
Atajos de teclado Esc para cerrar
En las diapositivas con respuestas ocultas, → las revela una por una antes de avanzar.