czay.dev
0/10
Hojas de ruta

Matriz de decisión para escalar el backend (de 0 a 1M de usuarios)

Esta hoja de ruta interactiva acompaña al vídeo 'The Over-Engineering Trap: Why You Shouldn't Setup Kafka and Microservices for Small Projects'. Una de las trampas más comunes en la ingeniería de software es montar 15 microservicios, Kubernetes y Kafka para un proyecto sin usuarios activos, y pasarte todo el tiempo depurando infraestructura en lugar de lanzar producto.

La buena ingeniería no consiste en elegir la herramienta más compleja para cada proyecto, sino en construir la solución más adecuada, con el mínimo coste operativo y cero complejidad accidental. Explora las etapas de abajo para saber exactamente cuándo introducir cada capa de arquitectura a medida que crece tu base de usuarios; tu progreso se guarda automáticamente en el navegador.

  • EsencialDomínalo bien antes de postularte
  • RecomendableAparece mucho en ofertas de empleo y te da ventaja
  • Más adelanteCuando ya estés trabajando y lo necesites

Haz clic en un tema para ver qué necesitas saber y dónde aprenderlo.

  1. 01

    Etapa 1: monolito modular limpio (0 - 50K DAU)

    No dividas la arquitectura hasta que se haya demostrado el encaje producto-mercado. Un único despliegue, cero latencia de red y consistencia ACID completa.

  2. 02

    Etapa 2: aliviar la presión sobre la base de datos (50K - 150K DAU)

    Elimina cuellos de botella antes de dividir servicios: sustituye el I/O de disco por caché en RAM y réplicas de lectura.

  3. 03

    Etapa 3: colas de mensajes asíncronas (150K - 500K DAU)

    Nunca hagas esperar a los usuarios en el ciclo HTTP: delega los correos, la generación de facturas y los webhooks en workers en segundo plano.

  4. 04

    Etapa 4: microservicios por dominio y arquitectura orientada a eventos (500K+ DAU)

    Ahora sí es el momento de los microservicios: divide en servicios de dominio solo cuando el tamaño del equipo o necesidades de escalado distintas lo exijan.

Tema por tema

Todos los temas del mapa con su descripción, qué saber y recursos, en una sola lista.

  1. 01Etapa 1: monolito modular limpio (0 - 50K DAU)

    • Arquitectura de monolito modular· Esencial

      Construye un único monolito donde los límites de dominio se aíslan por carpetas (módulos) con Fastify, NestJS, Go o Django. La comunicación entre módulos se hace mediante llamadas a funciones en memoria, no por la red (0 ms de latencia).

      Lo que deberías saber

      • Los módulos nunca consultan directamente las tablas de la base de datos de otros; interactúan a través de interfaces de servicio públicas estrictas.
      • Un solo servidor bien configurado con PostgreSQL correctamente indexado maneja sin problema más de 3.500 solicitudes por segundo (RPS).
      • Una única imagen de Docker y un pipeline de CI/CD te permiten publicar actualizaciones en segundos.

      Recursos

    • Índices de base de datos y connection pooling· Esencial

      El 90% de los sistemas que se vuelven lentos sufren por índices que faltan y pools de conexiones agotados, no por falta de CPU.

      Lo que deberías saber

      • Añade índices B-Tree en todas las claves foráneas y en las columnas habituales de WHERE / ORDER BY; verifica los planes de consulta con EXPLAIN ANALYZE.
      • Coloca PgBouncer delante de PostgreSQL para multiplexar miles de conexiones de cliente en 50-100 conexiones a la base de datos.

      Recursos

  2. 02Etapa 2: aliviar la presión sobre la base de datos (50K - 150K DAU)

    • Patrón Cache-Aside con Redis· Esencial

      Guarda en la RAM de Redis los datos que se leen con frecuencia pero cambian poco (perfiles de usuario, configuraciones, feed de inicio), reduciendo la latencia de 450 ms de I/O de disco a 1,2 ms de aciertos en RAM.

      Lo que deberías saber

      • Consulta primero Redis (Cache Hit). Si no está, léelo de la base de datos, rellena Redis y devuélvelo (Cache Miss).
      • Asigna siempre TTL razonables a las claves de caché; una caché sin límites provoca un consumo excesivo de memoria.

      Recursos

    • Separación de lectura / escritura y réplicas de lectura· Recomendable

      El tráfico web suele ser un 85% de lecturas (SELECT) y un 15% de escrituras (INSERT/UPDATE). Descarga el tráfico de lectura en instancias réplica.

      Lo que deberías saber

      • Dirige las operaciones de escritura a la base de datos primaria y descarga las consultas de analítica y búsqueda, con mucha lectura, en las réplicas de lectura.
      • Ten en cuenta el retraso de replicación en los recorridos críticos del usuario (por ejemplo, leer los pedidos justo después de finalizar la compra).
    • CDN y distribución de recursos estáticos· Esencial

      Cachea imágenes, fuentes, bundles de JS/CSS y respuestas públicas de la API en Cloudflare Edge para eliminar las solicitudes al servidor de origen.

      Lo que deberías saber

      • Las solicitudes se resuelven en 10-20 ms en los nodos edge globales antes de llegar a tu servidor de origen.

  3. 03Etapa 3: colas de mensajes asíncronas (150K - 500K DAU)

    • Colas de trabajos con BullMQ / RabbitMQ· Esencial

      Nunca ejecutes de forma síncrona, dentro del ciclo solicitud-respuesta HTTP, ninguna tarea que tarde más de 50 ms.

      Lo que deberías saber

      • Cuando un usuario dispara una acción, la API encola el trabajo y responde con '200 OK - Accepted' en 18 ms.
      • Workers dedicados en segundo plano procesan la cola; si un worker falla, los trabajos encolados se conservan sin problema.

      Recursos

    • Estrategia de reintentos y Dead Letter Queue (DLQ)· Esencial

      Cuando un servicio de terceros (SendGrid, Stripe) sufre una caída, no hagas fallar las solicitudes del usuario; reintenta de forma inteligente en segundo plano.

      Lo que deberías saber

      • Aplica Exponential Backoff con jitter para reintentar con seguridad los fallos transitorios.
      • Envía los trabajos que fallan de forma permanente a una Dead Letter Queue (DLQ) y lanza una alerta operativa.

  4. 04Etapa 4: microservicios por dominio y arquitectura orientada a eventos (500K+ DAU)

    • Descomposición de servicios guiada por dominio (DDD)· Esencial

      No descompongas todo el sistema de la noche a la mañana; extrae primero los dominios más autónomos (Auth, Pagos, Notificaciones).

      Lo que deberías saber

      • Cada servicio debe ser dueño de su propia base de datos privada (Database-per-Service); compartir bases de datos es un antipatrón.
      • Divide en microservicios cuando 5 o más equipos independientes necesiten desplegar de forma autónoma sin bloqueos de release.

      Recursos

    • Event streaming con Apache Kafka· Esencial

      Las llamadas HTTP síncronas entre microservicios provocan fallos en cascada; migra a una arquitectura asíncrona orientada a eventos.

      Lo que deberías saber

      • Cuando se crea un pedido, emite un evento 'OrderCreated' en lugar de llamar a 5 endpoints REST posteriores.
      • Usa el Transactional Outbox Pattern para garantizar que la actualización de la base de datos y la publicación del evento sean atómicas.

      Recursos

    • Distributed Tracing y OpenTelemetry· Recomendable

      Cuando una solicitud tarda 4 segundos a través de 15 microservicios, los Correlation ID y el tracing con OpenTelemetry son la única forma de localizar el cuello de botella.

      Lo que deberías saber

      • Genera un Trace ID único en el API gateway y propágalo en las cabeceras de todos los servicios posteriores.