Arquitectura de software
Definimos las decisiones estructurales que evitan reescrituras tempranas. Trade-offs explícitos, no dogmas. El documento de arquitectura que entregamos tiene que poder sostenerse frente a cualquier pregunta técnica.
¿Cuándo necesitás arquitectura?
Estás arrancando un producto y no querés tomar decisiones técnicas que van a costar caro en 12 meses.
Tu sistema actual no aguanta el crecimiento previsto y necesitás un plan antes de invertir en infraestructura.
Tenés un monolito que quisieras dividir pero no sabés si tiene sentido ni cómo hacerlo sin romper todo.
Estás integrando múltiples sistemas y los contratos entre servicios no están claros.
Los costos de infraestructura crecen más rápido que el producto y no tenés visibilidad de por qué.
Tu equipo crece y las decisiones técnicas no están documentadas — cada dev toma decisiones distintas.
Qué definimos
Diseño de alto nivel
- Partición del sistema: monolito modular vs microservicios vs serverless
- Límites de dominio y contextos acotados (DDD)
- Estrategia de comunicación: sync vs async, REST vs gRPC vs eventos
- Diagrama C4 nivel 1 (contexto) y nivel 2 (contenedores)
Estrategia de datos
- Modelo de datos y diseño de base de datos
- Estrategia de consistencia: transacciones distribuidas, sagas, outbox
- Caché: qué, dónde y cuándo
- Migraciones y evolución del esquema sin downtime
Observabilidad y operación
- Estrategia de logging, métricas y trazabilidad
- Alertas y SLOs definidos desde el diseño
- Configuración de entornos y gestión de secretos
- Plan de disaster recovery y backup
Decisiones de plataforma
- Stack tecnológico con justificación y trade-offs
- Infraestructura: cloud provider, containers, serverless
- CI/CD y estrategia de deploy (blue-green, canary, feature flags)
- Seguridad: autenticación, autorización, límites de exposición
El documento de arquitectura (ADR)
Un documento técnico que puede sostenerse frente a cualquier pregunta. No es una presentación de diapositivas — es una referencia que el equipo va a consultar durante meses.
- 01
Contexto y drivers — qué problema resuelve y qué restricciones existen (técnicas, de negocio, de equipo).
- 02
Decisiones registradas — cada decisión importante con su contexto, alternativas evaluadas y justificación.
- 03
Diagramas C4 nivel 1 y 2 — contexto del sistema y contenedores con sus interacciones.
- 04
Trade-offs explícitos — qué ganamos y qué perdemos con cada decisión. Sin dogmas.
- 05
Plan de implementación por fases — cómo llegar de donde están hoy a donde necesitan estar, en pasos ejecutables.
- 06
Riesgos identificados — qué puede salir mal y cómo mitigarlo.
Monolito o microservicios: cómo decidimos
La respuesta no es universal. Depende del tamaño del equipo, la madurez del dominio, los requisitos de escala y el presupuesto de operación.
| Factor | Monolito modular | Microservicios |
|---|---|---|
| Tamaño del equipo | Ideal para equipos < 10 devs | Necesario con equipos > 15 devs con ownership por servicio |
| Madurez del dominio | Dominio en exploración o cambio frecuente | Dominio estable con límites claros |
| Requisitos de escala | Escala uniforme — todo el sistema escala junto | Escala diferenciada por servicio |
| Costo operativo | Bajo — un deploy, un proceso, un log | Alto — orquestación, service mesh, observabilidad distribuida |
| Time to market | Más rápido en etapas tempranas | Más lento al inicio, más flexible después |
Preguntas frecuentes
¿Cuánto dura un engagement de arquitectura?
Entre 1 y 3 semanas según la complejidad. La primera semana es relevamiento y entrevistas. La segunda es diseño y documentación. La tercera es revisión con el equipo del cliente.
¿Pueden trabajar con nuestro equipo técnico existente?
Sí. Hacemos al menos una sesión de arquitectura con el equipo técnico del cliente. Las decisiones tienen que tener buy-in del equipo que las va a implementar.
¿El ADR es suficiente para que nuestro equipo implemente?
Sí. El ADR incluye suficiente detalle para que un equipo técnico competente lo implemente. Si necesitás acompañamiento en la implementación, podemos hacerlo como retainer.
¿Hacen arquitectura para sistemas que ya existen?
Sí. Muchas veces el trabajo es documentar y mejorar la arquitectura de un sistema existente, no diseñar desde cero. Arrancamos con una auditoría de la arquitectura actual.
¿Qué pasa si en 6 meses la arquitectura que definieron ya no aplica?
El ADR documenta el contexto en el que se tomaron las decisiones. Si el contexto cambia, las decisiones se revisitan. Esto es normal y esperado — una buena arquitectura es evolucionable, no permanente.
¿Estás tomando decisiones técnicas importantes sin un documento que las respalde?
Un ADR bien hecho es la diferencia entre un sistema que escala con el negocio y uno que lo frena. La primera conversación es sin compromiso.
Iniciar conversaciónOtros servicios