Caso: arquitectura core para una plataforma en crecimiento

Contexto

Una compañía con producto digital había llegado a ese punto incómodo en el que el crecimiento confirma que el producto funciona, pero también expone todo lo que se construyó con prisa. Identidad, permisos, integraciones y gateways estaban repartidos entre decisiones tomadas en momentos distintos.

No era una situación de caos. El sistema funcionaba, había equipo y había producto. Precisamente por eso era delicado: tocar la base sin criterio podía frenar roadmap, introducir regresiones o convertir cada nueva funcionalidad en una negociación técnica.

Reto

El reto no era añadir una funcionalidad aislada. Era convertir capas invisibles en una base de producto: algo que negocio, ingeniería y operación pudieran entender, extender y gobernar.

Había que decidir dónde terminaba identidad, dónde empezaba dominio, qué responsabilidades debía asumir el gateway y cómo evitar que los permisos se convirtieran en lógica duplicada por toda la plataforma.

Decisiones

Separar identidad, acceso, gateway y lógica de dominio para que cada capa tuviera una responsabilidad discutible y mantenible.

Diseñar APIs con contratos claros, pensando en uso interno, evolución futura y errores operativos.

Convertir seguridad y permisos en decisiones explícitas de producto, no en comprobaciones dispersas.

Alinear experiencia de desarrollo y observabilidad para que el equipo pudiera detectar problemas sin conocimiento tribal.

Qué cambió

La plataforma ganó una base más legible para producto, ingeniería y operación. Las conversaciones dejaron de depender de “dónde está eso en el código” y empezaron a apoyarse en un mapa común de responsabilidades.

El cambio importante no fue sólo técnico. También cambió la forma de decidir: nuevas funcionalidades, integraciones y permisos podían evaluarse contra una arquitectura compartida, no contra excepciones acumuladas.

Qué demuestra

Criterio para construir capas core: las partes que casi nadie ve, pero que determinan si un producto puede escalar con confianza. También demuestra una forma de trabajar que no trata la arquitectura como un diagrama, sino como una herramienta para que el equipo decida mejor.