Por qué no deberías usar Kafka ni microservicios en proyectos pequeños (sobreingeniería)

Hay una trampa seductora en la que cae casi todo ingeniero de software al empezar un proyecto desde cero: diseñar un sistema con cero usuarios activos como si diez millones de personas fueran a golpearlo mañana por la mañana.

Abres la pizarra de arquitectura: 12 microservicios independientes, un clúster de Apache Kafka para eventos asíncronos, bases de datos aisladas por servicio, gRPC para la comunicación entre servicios y una elaborada malla de Kubernetes solo para mantener todo a flote.

Suena a "ingeniería de verdad" que puedes presumir con orgullo en LinkedIn. Pero la dura realidad de producción es simple: desplegar Kafka y microservicios para una app con 100 visitantes diarios no es buena ingeniería: es asfixiar el producto antes de que dé su primer respiro.

1. El mito de "Netflix lo hace así"

La causa raíz de esta epidemia de sobreingeniería es leer los blogs de ingeniería de las grandes tecnológicas sin entender su contexto organizativo y operativo.

Esto es lo que la gente olvida convenientemente: ni Netflix, ni Uber, ni Amazon empezaron con microservicios el primer día.

• Netflix funcionó con una arquitectura monolítica durante años, hasta que una corrupción masiva de la base de datos en 2008 forzó una transformación. Su migración a microservicios no se debió a "tecnología de moda", sino a la escala organizativa: cientos de desarrolladores pisándose unos a otros en un solo repositorio y una única base de datos que chocaba con los límites físicos del hardware.
• Shopify sigue manejando hoy un porcentaje enorme del tráfico global de comercio electrónico del Black Friday sobre un monolito modular bien diseñado, construido con Ruby on Rails.

Si estás construyendo un producto con un equipo de 2 a 5 ingenieros (o en solitario), tu principal amenaza existencial no es si tu base de datos aguanta 100.000 escrituras por segundo. Tu principal amenaza es avanzar demasiado despacio, no poder iterar y gastar el 80 % de tu capacidad de desarrollo arreglando tuberías distribuidas en lugar de aportar valor al cliente.

2. El impuesto oculto de los sistemas distribuidos prematuros

En una aplicación monolítica, ejecutar una transacción de negocio (await orderService.createOrder()) toma nanosegundos en memoria. Si algo falla a mitad de camino, una transacción de base de datos estándar (ROLLBACK) restaura el estado de forma determinista.

En cuanto te divides en microservicios y un bus de eventos como Kafka, heredas todo un catálogo de pesadillas de sistemas distribuidos:

1. Transacciones distribuidas y patrones Saga: el servicio de pagos cobró la tarjeta, pero el servicio de inventario se cayó antes de reservar el stock. ¿Cómo emites transacciones compensatorias de forma fiable?
2. Latencia e inestabilidad de red: llamadas a funciones en memoria de menos de un milisegundo se convierten en viajes HTTP/gRPC de 20–50 ms por una red que es inherentemente poco fiable.
3. Pesadilla de observabilidad: rastrear un bug ahora exige trazado distribuido (OpenTelemetry, Jaeger) e infraestructura de logs centralizada solo para averiguar qué cola perdió un mensaje.
4. Parálisis en los despliegues: en lugar de desplegar un único binario o contenedor con un comando, estás orquestando migraciones de esquema entre servicios, versionado de APIs y complejas matrices de CI/CD.

3. La escalera pragmática de escalado

Entonces, ¿cuál es la alternativa pragmática? ¿Cómo deberías hacer evolucionar realmente la infraestructura de tu backend a medida que crece el volumen de usuarios?

      ▲
     / \     Stage 4: 1M+ DAU & Multiple Independent Teams
    /   \    ➔ Event-Driven (Kafka), Kubernetes, Polyglot Microservices
   /-----\   
  /       \   Stage 3: 250k - 1M DAU
 /         \  ➔ Read-Replicas, Asynchronous Queues (BullMQ / RabbitMQ)
/-----------\ 
/             \ Stage 2: 50k - 250k DAU
/               \ ➔ Redis Cache (Cache-Aside), Connection Pooling (PgBouncer)
/-----------------\
/                   \ Stage 1: 0 - 50k DAU
/                     \ ➔ Modular Monolith + Single Managed PostgreSQL

Etapa 1: 0 – 50.000 DAU (monolito modular limpio)

• Arquitectura: una única aplicación en Node.js (Fastify/NestJS), Go o Python.
• Base de datos: una única instancia gestionada de PostgreSQL o MySQL.
• Estrategia: escribe código modular con límites de dominio claros, no espagueti. Si alguna vez necesitas extraer un servicio, los límites ya existirán, pero mantenlos hoy ejecutándose en el mismo proceso. Esta configuración puede manejar con comodidad decenas de miles de usuarios activos diarios con latencias de menos de 50 ms en un VPS de 20 $/mes.

Etapa 2: 50.000 – 250.000 DAU (caché y gestión de conexiones)

• Cuello de botella: las consultas de lectura repetidas disparan el uso de CPU de la base de datos.
• Solución:
  • Coloca Redis delante de la base de datos con el patrón Cache-Aside. Sirve las lecturas de alta frecuencia directamente desde la RAM en 1–2 milisegundos.
  • Introduce PgBouncer o un pool de conexiones para evitar el agotamiento de conexiones durante los picos de tráfico.

Etapa 3: 250.000 – 1.000.000 DAU (separación lectura/escritura y workers asíncronos)

• Cuello de botella: las tareas pesadas síncronas (enviar emails, procesar subidas, generar informes) bloquean los hilos de la API. Las lecturas de la base de datos saturan el nodo primario.
• Solución:
  • Delega las tareas no críticas a colas de trabajos en segundo plano ligeras como BullMQ o RabbitMQ.
  • Añade 1–2 réplicas de lectura a la base de datos, desviando las consultas con mucha lectura lejos del maestro de escritura.

Etapa 4: más de 1.000.000 DAU (orientada a eventos y extracción de dominios)

• ¿Por qué ahora? Los equipos de ingeniería independientes (Pagos, Búsqueda, Identidad) necesitan desplegar sin pisarse, y los logs de auditoría generan terabytes de eventos secuenciales.
• Solución: ahora sí se justifican Kafka, el streaming de eventos y los microservicios dedicados, porque los cuellos de botella organizativos y arquitectónicos por fin superan el coste operativo.

¿No sabes qué etapa necesita tu proyecto?

Si quieres una forma interactiva de diagnosticar tu volumen actual de usuarios, identificar los próximos cuellos de botella y ver recomendaciones exactas de herramientas para cada fase, echa un vistazo a nuestro roadmap interactivo:

👉 Explora la matriz interactiva de decisión para escalar el backend

Conclusión

La mejor arquitectura nunca es la que tiene más piezas móviles. La mejor arquitectura es la que resuelve los objetivos de negocio con la menor complejidad y la mayor velocidad de ingeniería.

Dedica los dos meses que habrías perdido configurando Kafka y Kubernetes a pulir la experiencia de usuario. Mantén tu monolito limpio y modular; cuando llegue el tráfico, escalarlo de forma sistemática es mucho más fácil, e infinitamente más agradable.