Ecommerce Platform — Cap Bros

Problema que resuelve

La mayoría de microempresas que venden por redes sociales pierden ventas por procesos manuales: actualizar inventario en una hoja de cálculo, responder pedidos por mensaje directo, calcular envíos a mano y cuadrar pagos a fin de mes. Cap Bros elimina esa fricción ofreciendo una plataforma completa de ecommerce con un panel de administración que automatiza el negocio: productos, pedidos, pagos, métricas y decisiones basadas en datos.

El objetivo no era construir “otra tienda”, sino una base distribuida y orientada a eventos que pueda crecer con la empresa sin reescribir nada.

Stack y decisiones técnicas

El sistema está compuesto por dos repositorios independientes que se comunican mediante eventos:

• client-cap-bros — storefront público de cara al usuario final (catálogo, carrito, checkout, cuenta).
• admin-panel-cb — backoffice para gestión de productos, pedidos, pagos, usuarios y métricas.

Decisiones clave:

• Arquitectura orientada a eventos para desacoplar el storefront del admin: cuando entra un pedido, se publica un evento que dispara tareas paralelas (notificación, descuento de stock, pago, factura) sin bloquear al usuario.
• Procesos en segundo plano y asíncronos para tareas costosas (envíos masivos de email, conciliación de pagos, generación de reportes).
• Modelado de datos cuidadoso: normalización agresiva donde la coherencia importa (productos, inventario, pagos) y denormalización selectiva donde la lectura debe ser rápida (catálogo público, dashboards).
• Patrones de diseño aplicados sin sobre-ingeniería: Repository para el acceso a datos, Factory para creación de pedidos con políticas de descuento, Strategy para los métodos de pago.
• Seguridad por capas: validación en frontend y backend, hash de contraseñas con sal, tokens firmados, control de acceso por rol en cada endpoint del admin.

Decidir el modelo de base de datos fue el ejercicio más largo del proyecto: validar contra escenarios reales (devoluciones, promociones combinadas, productos con variantes) antes de escribir una línea de código.

Retos encontrados

1. Escalabilidad bajo picos de tráfico. Cuando una campaña en redes sociales explota, decenas de pedidos llegan en segundos. Sin desacoplo, el storefront caía bajo su propio peso.
2. Gestión de pagos confiable. Capturar el resultado de un pago externo en tiempo real es engañosamente difícil: hay timeouts, reintentos, pagos duplicados, webhooks fuera de orden.
3. Procesos en segundo plano y eventos en tiempo real. Necesitaba que el cliente viera “pedido confirmado” instantáneamente, pero las tareas pesadas tenían que ejecutarse fuera del request.
4. Coherencia entre los dos sistemas. Si el admin actualiza el precio o desactiva un producto, el storefront debe reflejarlo sin caché obsoleto.

Cómo resolví los retos

• Cola de tareas + workers para descargar trabajo del request principal. El usuario obtiene respuesta en milisegundos; el sistema termina el trabajo en segundo plano.
• Patrón de idempotencia en el handler de pagos: cada webhook entra con un idempotency_key, así reintentos del proveedor no generan pedidos duplicados.
• Eventos como contrato entre sistemas: ambos repos consumen los mismos esquemas de evento, lo que reduce acoplamiento y permite versionar cambios.
• Modelado iterativo con mini-prototipos: antes de comprometerme con un esquema, construía mini-sistemas de prueba para validar la idea contra casos límite reales.
• Documentación constante: lo que no entendía lo investigaba a fondo (papers, RFCs, documentación oficial) y me apoyaba en IA como segundo par de ojos —nunca como autor único.

Qué aprendí

• A modelar dominios complejos (pagos, inventario, devoluciones) sin caer en sobre-ingeniería.
• A diseñar para fallos: idempotencia, reintentos, dead letter queues, observabilidad.
• A decidir entre coherencia fuerte y eventual según el caso de uso: el carrito puede ser eventual, el pago jamás.
• A pensar como arquitecto de software: priorizar interfaces claras entre subsistemas por encima de la elegancia interna de cada uno.
• A trabajar con IA bajo el estándar Human-In-The-Loop: la IA acelera la exploración, yo decido la arquitectura y reviso cada decisión técnica.

Estado actual

En producción para los clientes piloto. Código fuente no público por acuerdo comercial; demo bajo petición.