Servicios04 / 07

Sistemas que siguen siendo comprensibles cuando crecen

La pregunta que casi nunca se hace al empezar un rediseño es la más importante: ¿este sistema es difícil porque el dominio lo es, o porque nadie lo ordenó? La respuesta cambia todo. Un dominio genuinamente complejo pide límites explícitos y modelos separados; un desorden acumulado pide, casi siempre, menos piezas y no más.

Por eso no llego con una arquitectura de referencia. Llego con preguntas sobre el dominio: qué cambia junto, qué se puede desplegar por separado sin coordinar equipos, dónde está el invariante que no se puede romper nunca. De ahí salen los límites, y solo después se decide si son módulos de un mismo despliegue o servicios independientes.

Prefiero un sistema aburrido que se entienda a las tres de la mañana antes que uno elegante que solo yo sepa operar. Microservicios cuando el dominio y la organización lo justifican; un monolito modular bien ordenado cuando la respuesta honesta es que un equipo de seis personas no necesita doce despliegues.

Formato
Diseño y auditoría
Escalabilidad
+300%
Infraestructura
−40%
Recuperación
Minutos
Escribirme
Alcance

¿Qué involucra?

  1. 01Arquitecturas de microservicios
  2. 02Diseño orientado a eventos
  3. 03Sistemas distribuidos
  4. 04Arquitecturas cloud-native
  5. 05Patrones de escalabilidad
Método

¿Cómo se aborda?

  1. Paso 01

    Descubrimiento del dominio

    Event storming con la gente que conoce el negocio, no solo con desarrollo. De ahí salen los contextos acotados y el lenguaje común. Es la parte que más se salta y la que más caro cuesta saltarse: unos límites mal puestos se pagan durante años.

  2. Paso 02

    Decisiones registradas, no heredadas

    Cada decisión estructural queda como ADR: qué se decidió, qué alternativas se descartaron y bajo qué supuestos. Cuando los supuestos cambien —y cambian— se podrá revisar la decisión sin arqueología.

  3. Paso 03

    Evolución incremental, no big bang

    El patrón strangler fig: el sistema nuevo crece alrededor del viejo y le va quitando responsabilidades, con la posibilidad de volver atrás en cada paso. Una reescritura completa es la forma más cara de descubrir que el sistema anterior hacía cosas que nadie documentó.

  4. Paso 04

    Resiliencia probada, no supuesta

    Timeouts, reintentos con backoff, circuit breakers y degradación explícita. Y después, ejercicios donde se rompe algo a propósito en un entorno controlado, porque un plan de recuperación que nunca se ensayó es un documento, no una capacidad.

Decisión

Difícil por el dominio, o difícil por desorden

Es la pregunta que casi nadie hace al empezar un rediseño, y la que cambia todo el resultado. Un dominio genuinamente complejo pide límites explícitos y modelos separados. Un desorden acumulado pide, casi siempre, menos piezas y no más.

Confundirlas es el error caro. Partir en microservicios un sistema que solo estaba mal ordenado multiplica el desorden por el número de despliegues, y añade latencia de red y consistencia eventual a un problema que era de nombres y responsabilidades.

En Sky Airline la respuesta fue partir: había que construir la nueva AppSales mientras la anterior seguía sirviendo más de un millón de transacciones mensuales, y eso exige piezas que se despliegan por separado. En otros casos la respuesta honesta ha sido que un equipo de seis personas no necesita doce despliegues, y que un monolito modular bien ordenado entrega antes y se opera mejor.

  • Event storming con negocio, no solo con desarrollo
  • Los límites salen del dominio; el despliegue se decide después
  • Microservicios cuando hay equipos que necesitan no coordinarse
  • Strangler fig: el sistema nuevo crece alrededor del viejo
  • Cada etapa con valor propio y camino de vuelta
Evidencia

¿Dónde lo he hecho?

Yummy Inc. · Microservicios de pagos
Arquitectura de medios de pago que mejoró la confiabilidad del sistema
+40% confiabilidad
Wompi (Grupo Bancolombia)
Rearquitectura para soportar Open Banking como iniciador de pagos
−35% proceso
Sky Airline · Servicios y mobile
Microservicios de perfiles y la nueva AppSales, con la anterior aún en producción
5+ servicios

Las cifras vienen de sistemas en producción. La trayectoria completa está en Sobre mí.

Ejecución

Prácticas y entregables

Prácticas

  • Domain-Driven Design
  • Event storming
  • ADRs
  • Strangler fig
  • CQRS y event sourcing
  • Chaos engineering
  • Fitness functions
  • C4 model

Entregables

  • Mapa de contextos acotados
  • Diagramas C4 y ADRs fechados
  • Plan de migración por etapas reversibles
  • Presupuesto de rendimiento y escalabilidad
  • Guía de operación y recuperación

Stack

  • TypeScript
  • Go
  • PostgreSQL
  • Kafka
  • RabbitMQ
  • Terraform
Preguntas

Lo que suelen preguntarme

¿Siempre recomiendas microservicios?
No. Recomiendo microservicios cuando hay equipos que necesitan desplegar sin coordinarse y partes del sistema con perfiles de carga distintos. Con un equipo pequeño, un monolito modular entrega más rápido y se opera mejor.
¿Cuánto dura una auditoría de arquitectura?
De dos a cuatro semanas, según el tamaño. Termina en un informe con los riesgos ordenados por impacto y un plan de etapas, cada una con valor por sí misma.
¿Se puede migrar sin congelar el producto?
Sí, y es la única forma que recomiendo. Con strangler fig y feature flags el sistema nuevo se va llevando tráfico real de manera gradual y reversible, sin una fecha de corte que nadie puede garantizar.
¿Qué entregas al final?
Diagramas C4, ADRs, el plan por etapas y —cuando el alcance lo incluye— el andamiaje inicial ya construido y desplegado, para que la primera etapa no empiece desde una hoja en blanco.
Catálogo
Ver todos

Otros frentes