Arquitectura de una plataforma B2B para seguimiento de afiliados y atribución de ingresos
Durante el desarrollo de una plataforma B2B comercial en el ámbito del seguimiento de afiliados y la atribución de ingresos, uno de los desafíos centrales fue diseñar un backend capaz de procesar un flujo continuo de eventos e-commerce externos sin comprometer la lógica de negocio interna.
En la práctica, esto implicaba separar un núcleo de dominio estable de una capa de integración de alta carga. Sin esta separación, los picos de tráfico externos — pedidos, actualizaciones de estado, eventos de marketplace — habrían impactado directamente las partes críticas del sistema como la lógica de comisiones o las reglas financieras.
Separación del núcleo de negocio y la capa de integración
La arquitectura se construyó sobre dos capas independientes.
El núcleo de negocio gestionaba todo lo que debía permanecer estable: estructuras empresariales, jerarquías de roles, reglas de comisiones y lógica financiera. Esta parte del sistema debía ser predecible y estrictamente controlada.
La capa de integración, en cambio, procesaba los datos externos — eventos entrantes, flujos de sincronización e interacciones con marketplaces. Estaba diseñada para absorber carga y variabilidad sin filtrar esa complejidad hacia el núcleo del dominio.
Esta separación permitió escalar el sistema bajo carga elevada manteniendo la coherencia de los procesos internos.
RBAC y espacio de trabajo multinivel
Otro componente importante del sistema era el modelo interno de espacio de trabajo y control de acceso.
Para una plataforma B2B multiusuario, implementamos un sistema Role-Based Access Control (RBAC) de múltiples niveles.
El control de acceso se aplicaba no solo a nivel de interfaz, sino también en rutas, operaciones de datos y endpoints API. Esto era fundamental porque diferentes roles — propietarios de empresa, gestores, operadores, agentes, observadores — interactúan con el mismo sistema de formas muy distintas.
A medida que crecía el número de roles y entidades, este modelo permitió mantener el comportamiento predecible en lugar de caótico.
Arquitectura API híbrida
La capa API seguía un enfoque híbrido.
Para operaciones estándar, los endpoints CRUD se generaban a partir de los modelos de dominio y la infraestructura compartida. Esto mantenía el desarrollo rápido y coherente.
Pero para la lógica crítica — operaciones financieras, agregaciones, dashboards, enrutamiento personalizado — todo se implementaba manualmente. Eran las partes donde perder el control no era una opción.
En definitiva, este equilibrio entre automatización y control manual permitió avanzar rápidamente sin introducir inestabilidad en el sistema.