Arquitectura de Software & Escalabilidad

Cuándo conviene rediseñar (o repensar) la arquitectura

• Los tiempos de respuesta empeoran sin razón evidente. Suele ser síntoma de un modelo de datos o un patrón de acceso que era válido a 1.000 usuarios pero deja de serlo a 100.000.
• Cada feature nueva toca media base de código. Acoplamiento alto: o se reorganiza la arquitectura, o el coste de cada cambio sigue creciendo hasta hacerlo inviable.
• Tenéis miedo de tocar partes del sistema. Síntoma típico de cobertura de tests insuficiente combinado con responsabilidades difusas. Es un problema arquitectónico, no de testing.
• El equipo no escala porque hay un único punto de paso. Si todo el código pasa por la misma persona o el mismo módulo, no podéis incorporar developers sin perder velocidad.
• Vais a entrar en un sector con requisitos nuevos (compliance, alta disponibilidad, eventos en tiempo real, integraciones con terceros críticos). Mejor diseñar antes de comprometeros con clientes.
• Os preparáis para una ronda y los inversores van a preguntar. La pregunta "¿esto aguanta 10x usuarios?" tiene respuesta concreta solo si tenéis la arquitectura mapeada y argumentada.

Decisiones clave que tomamos en cada proyecto

No hay arquitecturas universalmente correctas — hay decisiones que encajan o no con vuestra fase. Estas son las que repasamos siempre:

• Monolito modular vs. microservicios. En la mayoría de startups con menos de 20 personas técnicas, un monolito modular bien diseñado es más rápido, más barato y más fácil de evolucionar. Microservicios prematuros son la forma más cara de generar deuda operacional.
• SQL vs. NoSQL. Por defecto, PostgreSQL. NoSQL aporta solo cuando hay un patrón de acceso específico que SQL gestiona mal — y ese caso es menos común de lo que parece.
• Cloud provider y nivel de lock-in. AWS, GCP o Azure. La decisión depende del equipo que os va a operar la infraestructura, no de la moda. Equipo y arquitectura son la misma decisión.
• Eventos vs. integraciones síncronas. Si conectáis con sistemas externos, la decisión correcta entre webhooks, eventos o batch determina la robustez del producto. Revisamos esto en cada integración crítica.
• Estrategia de cacheo y observabilidad. Sin caché bien pensado, escalar es caro. Sin observabilidad, los problemas se diagnostican demasiado tarde. Las dos van juntas.
• Roadmap de evolución técnica. No diseñamos la arquitectura final desde el día 1. Diseñamos un camino donde cada hito sea sostenible y se pueda evolucionar al siguiente sin reescritura masiva.

Casos reales de arquitecturas que hemos diseñado

• Bracelit — Plataforma de pagos cashless NFC con 2M+ usuarios y 25M€ procesados. La decisión arquitectónica de mantener un monolito Laravel bien estructurado en backend (en lugar de partir en microservicios prematuramente) permitió operar con un equipo deliberadamente pequeño durante años. Stack: Laravel, Angular, Ionic, Astro, AWS.
• Wegow — Plataforma de eventos musicales con 100k usuarios diarios y 4M+ registrados. Diseño y evolución de una arquitectura que sostiene picos de release de eventos sin colapsar. Stack: Vue, Django, PostgreSQL, AWS.
• Satya Legal — Plataforma B2B y CRM a medida para un despacho de abogados de startups. Stack: Astro, React, Django. Ejemplo de arquitectura dimensionada exactamente a la fase del producto.

Recursos y guías relacionadas

Materiales que tocan decisiones arquitectónicas concretas:

• Cómo dimensionar un equipo de software — La arquitectura define el tamaño del equipo, no al revés.
• Qué perfiles técnicos contratar según el tamaño del producto — Tabla por fase con las decisiones técnicas que cada perfil habilita o limita.
• Roadmap tecnológico de MVP a producto escalable — Cómo planificar la evolución técnica sin reescribir el producto en 18 meses.
• Cómo evitar deuda técnica desde el primer día — Las decisiones arquitectónicas tempranas que más caro salen cuando se equivocan.
• Subcontratar software vs. equipo interno — Cómo subcontratar arquitectura sin perder control técnico.