Simulador de Decisiones

A los 4 meses, el equipo lleva un 30% del trabajo. El monolito sigue recibiendo features nuevas porque el negocio no puede esperar. Ahora tienes dos sistemas que mantener y el equipo está dividido. El CTO empieza a preguntar cuándo estará listo.

Lección: Las reescrituras completas casi nunca terminan a tiempo. El negocio no se detiene mientras reescribes.

A los 3 meses, extrajiste el servicio de notificaciones. Los deploys del monolito son un poco más rápidos. El equipo aprendió sobre comunicación entre servicios, service discovery y monitoreo distribuido. Ahora puedes planificar la siguiente extracción con más confianza.

Lección: El patrón Strangler Fig permite migrar gradualmente con riesgo controlado. Cada extracción enseña lecciones para la siguiente.

A los 2 meses, el monolito está organizado en módulos con interfaces claras. Los conflictos de merge se redujeron un 60%. Los deploys siguen tardando 45 minutos, pero ahora puedes hacer deploys parciales por módulo. El equipo tiene una base sólida para extraer servicios en el futuro si es necesario.

Lección: A veces la mejor arquitectura distribuida es la que no necesitas. Un monolito bien organizado puede escalar más de lo que crees.

PostgreSQL maneja bien las 500K filas y las consultas complejas. A los 6 meses, las lecturas empiezan a saturar la base de datos. Agregas una read replica y el problema se resuelve. El historial de cambios lo implementas con una tabla de auditoría y triggers.

Lección: PostgreSQL es una elección sólida para la mayoría de los casos. No subestimes lo lejos que puede llegar una base de datos relacional bien configurada.

MongoDB funciona bien al principio. A los 3 meses, descubres que las consultas de agregación con múltiples filtros son más lentas de lo esperado. El schema flexible causó inconsistencias en los datos porque diferentes partes del equipo guardaban los documentos con estructuras ligeramente diferentes.

Lección: La flexibilidad de schema es un arma de doble filo. Sin disciplina, genera deuda técnica. MongoDB brilla cuando el modelo de datos es genuinamente jerárquico.

La combinación funciona muy bien para las lecturas. Pero a los 2 meses, descubres bugs de invalidación de caché: algunos usuarios ven datos stale después de actualizaciones. Implementas un sistema de invalidación basado en eventos y el problema se resuelve, pero la complejidad operativa aumentó significativamente.

Lección: Agregar caché resuelve problemas de rendimiento pero introduce problemas de consistencia. Solo agrega caché cuando realmente lo necesitas, no “por si acaso”.

Funciona, pero la reconciliación entre dos proveedores es compleja. Algunos pagos se procesan en Stripe y otros en PayPal, lo que complica los reportes financieros. Además, PayPal tiene su propia tasa de fallos — no es inmune. A los 3 meses, tienes un sistema más resiliente pero significativamente más complejo de operar.

Lección: Múltiples proveedores aumentan la disponibilidad pero multiplican la complejidad. Evalúa si el costo operativo justifica la mejora en disponibilidad.

Los reintentos automáticos resuelven el 90% de los fallos transitorios. Pero descubres un problema: algunos pagos se procesan dos veces porque el reintento llega cuando Stripe ya había procesado el primero (pero respondió con timeout). Implementas idempotencia con claves únicas y el problema se resuelve.

Lección: Los reintentos sin idempotencia son peligrosos. Siempre implementa idempotencia antes de implementar reintentos automáticos.

El circuit breaker detecta los fallos en segundos y deja de enviar requests a Stripe. Los usuarios ven un mensaje claro: “El sistema de pagos está temporalmente no disponible. Tu carrito está guardado — puedes completar la compra más tarde.” La experiencia no es perfecta, pero es honesta y no genera frustración.

Lección: A veces la mejor respuesta a un fallo es ser transparente con el usuario. No todos los problemas requieren soluciones técnicas complejas.