Proyecto
Gestión de organización de tiendas
Plataforma interna para calcular plantilla, tareas y operativa de tienda a partir de ventas, reposición, recepción, pedidos y carga real de trabajo.
- Java
- Spring Boot
- Kafka
- Kubernetes
- Docker
- Oracle
- MongoDB
- Redis
- Caffeine
- Microservicios
Contexto
De qué punto partíamos
Enfoque
Cómo lo trabajé
Reingeniería de una herramienta legacy hacia una plataforma más flexible y escalable, con configuración dinámica de fórmulas y excepciones, procesamiento distribuido y capas de caché en los flujos críticos.
Decisiones
Decisiones y compromisos relevantes
- Separar los datos transaccionales y de negocio en Oracle de la configuración flexible de cálculos en MongoDB para no mezclar estabilidad operativa con capacidad de adaptación.
- Utilizar un patrón tipo scatter-gather en los cálculos más costosos para repartir carga y poder escalar horizontalmente cuando la demanda lo exigía.
- Introducir una abstracción de transaccionalidad distribuida basada en tokens para mantener consistencia operativa entre microservicios sin caer en una saga completa.
- Aplicar doble nivel de caché con Redis y Caffeine para reducir latencia en lecturas repetidas y evitar recálculos innecesarios en los escenarios más calientes.
Resultado
Qué cambió
- Nueva herramienta preparada para dar soporte a más de 100k usuarios diarios en un contexto de operativa sensible y uso continuado.
- Mayor flexibilidad para ajustar fórmulas, excepciones y reglas de negocio sin convertir cada cambio en una reescritura técnica.
- Base más estable para evolucionar cálculos, operativa y capacidad de tienda con menos fricción.
Aprendizaje
Con qué me quedé
- Cuando el problema mezcla datos, concurrencia y negocio, la arquitectura solo funciona si la flexibilidad está pensada desde el principio.
- Escalar no consiste solo en procesar más, sino en saber dónde cachear, dónde distribuir y dónde mantener consistencia sin complicar el sistema.
- Fue uno de los proyectos que más me ayudó a pasar de desarrollador backend a líder técnico con responsabilidad real sobre decisiones de arquitectura.
Continuidad
Sigue explorando
Navega al caso anterior o siguiente, o salta a proyectos relacionados.
Más contexto
Lo que merece ampliar
Este caso trataba de orquestar cálculo operativo en tienda a escala: necesidades de personal, orden de tareas (reposición, recepción, pedidos) y reglas de plantilla en una sola plataforma. No era una aplicación visible hacia fuera, pero sí una pieza crítica para decidir cómo se organiza el trabajo diario.
El reto no era solo escalar. Había que combinar rapidez de respuesta, alta disponibilidad y flexibilidad de negocio dentro de una arquitectura distribuida. La plataforma recibía cientos de millones de mensajes al día, dependía de cálculos apoyados en información histórica y operativa muy pesada, y necesitaba cambiar reglas sin arrastrar al equipo a una reescritura continua.
Mi papel fue el de tech lead backend, participando tanto en desarrollo como en decisiones de arquitectura y coordinación técnica de un equipo de hasta siete personas. Me tocó bajar ideas a ADRs, repartir responsabilidades entre servicios y buscar un equilibrio serio entre consistencia, rendimiento y mantenibilidad. Una parte clave del trabajo fue impedir que la complejidad del dominio se convirtiera en complejidad accidental del sistema.
La reingeniería permitió dejar atrás limitaciones del legado y construir una base preparada para crecer sin perder gobernabilidad. Para mí fue uno de los proyectos que mejor resumen el tipo de problema donde más aporto: datos, concurrencia, reglas complejas y decisiones de arquitectura que no admiten frivolidad.