Micro Kafka Shop

Problema

Una plataforma de e-commerce con productos, pedidos y pagos suena a proyecto simple que se puede realizar un fin de semana, hasta que te das cuenta de que si necesitas que escale, el acoplamiento entre las diferentes piezas que conforman un sitio de ventas crea una fragilidad a la hora de crecer. Una caída del servicio de pagos no debería tumbar el catálogo de producos, y un pedido no debería depender de una llamada síncronica a una API de checkout que puede estar saturada o totalmente caída. El reto era construir tres servicios independientes que se mantengan comunicados a través de eventos en lugar de bases de datos compartidas o llamadas HTTP directas.

Solución

• Diseñé tres servicios backend con diferentes frameworks elegidos para crear un caso de uso real: Express para el catálogo de productos, Fastify para la gestión de pedidos y Hono para la capa de pagos. Cada uno posee su propia base de datos, PostgreSQL para productos vía Prisma, MongoDB para pedidos vía Mongoose, para que puedan evolucionar de forma independiente.
• Utilice Apache Kafka como bus de eventos. Cuando se crea un producto, el servicio de productos emite product.created; el servicio de pagos lo consume y crea un producto coincidente en Stripe. Un checkout exitoso emite payment.successful; el servicio de pedidos lo consume y persiste el pedido. Ningún servicio llama a otro directamente.
• Construí un paquete compartido de Kafka con tiempos de espera configurables, intervalos de heartbeat y manejo seguro de sesiones, para que cada productor y consumidor en el monorepo comparta la misma lógica de conexión sin duplicarla.
• Creé dos storefronts en Next.js, una tienda de clientes y un dashboard admin, compartiendo una librería de UI, definiciones de tipos y esquemas Zod. Clerk maneja la autenticación y el control de acceso por rol en cada endpoint del servicio, con roles user/admin forzados del lado del servidor a través de middlewares.
• Integré Stripe Checkout con Elements embebidos y webhooks: el servicio de pagos construye los ítems del carrito, devuelve un client secret y escucha checkout.session.completed para emitir eventos hacia adelante.

Resultado

• Los servicios se despliegan y escalan de forma independiente. El servicio de pedidos puede caer sin afectar la navegación de productos o las operaciones del admin, y viceversa.
• Añadir un nuevo servicio (notificaciones, analítica, recomendaciones) significa suscribirse a topics de Kafka existentes.
• El monorepo de Turborepo con tipos compartidos facilita identificar incompatibilidades entre contratos de servicios en tiempo de build.