Construir un CRM Fintech: Arquitectura Event-Driven en Google Cloud

En el panorama financiero actual, la velocidad y la fiabilidad no son simples características, sino requisitos de cumplimiento. Diseñar un sistema de gestión de clientes (CRM) para el sector Fintech requiere un cambio de paradigma respecto a los tradicionales sistemas monolíticos basados en bases de datos relacionales y llamadas síncronas. En esta guía técnica, basada en la experiencia de desarrollo del sistema BOMA, exploraremos cómo una arquitectura event-driven en Google Cloud Platform (GCP) puede resolver los desafíos de escalabilidad, coherencia y reactividad típicos del sector.

¿Por qué una Arquitectura Event-Driven en Fintech?

Un CRM Fintech no se limita a almacenar datos maestros. Debe reaccionar en tiempo real a depósitos, cambios de estado KYC (Know Your Customer), fluctuaciones del mercado e interacciones del usuario. Un enfoque tradicional Request/Response (HTTP síncrono) crea un acoplamiento estrecho entre los servicios, llevando a cuellos de botella y potenciales fallos en cadena.

La arquitectura event-driven (EDA) invierte este modelo. En lugar de servicios que se llaman directamente, los componentes emiten “eventos” (hechos ocurridos, como PaymentReceived o LeadCreated) que son consumidos asíncronamente por otros servicios. Según la documentación de Google Cloud Architecture, este patrón mejora drásticamente la resiliencia y la escalabilidad del sistema.

El Stack Tecnológico GCP: El Caso BOMA

Para el proyecto BOMA, la elección del stack tecnológico recayó en servicios gestionados serverless para minimizar la carga operativa y maximizar la escalabilidad:

• Google Pub/Sub: La columna vertebral de mensajería para la ingestión y distribución de los eventos.
• Cloud Functions (2nd Gen): Capa de computación para ejecutar la lógica de negocio en respuesta a los eventos.
• Firestore: Base de datos NoSQL documental para el estado de la aplicación y actualizaciones en tiempo real.
• BigQuery: Data warehouse para el análisis histórico y los informes de cumplimiento.

1. Desacoplamiento con Google Pub/Sub

El corazón palpitante de la arquitectura es Google Pub/Sub. Cada acción significativa en el CRM se publica como mensaje en un Topic específico.

Patrón de Implementación

Imaginemos el flujo de un nuevo usuario que se registra:

1. El frontend llama a una API Gateway.
2. La API publica un evento en el topic user-onboarding.
3. Pub/Sub garantiza la persistencia del mensaje y responde inmediatamente al cliente (baja latencia).

En este punto, diversas Subscriptions activan workers independientes:

• Sub A (CRM Core): Crea el perfil en Firestore.
• Sub B (Compliance): Inicia los controles contra el blanqueo de capitales (AML) mediante proveedor externo.
• Sub C (Notification): Envía el correo electrónico de bienvenida.

Best Practice Técnica: En Fintech, el orden de los eventos es crítico (no puedes retirar fondos antes de haberlos depositado). Utilizamos las Ordering Keys de Pub/Sub (ej. el ID de usuario) para garantizar que los mensajes relativos al mismo cliente sean procesados en orden secuencial, manteniendo aun así la escalabilidad paralela en usuarios diferentes.

2. Firestore: Base de Datos Documental y Real-Time

La elección de Firestore frente a Cloud SQL viene dictada por la necesidad de actualizaciones en tiempo real en el dashboard de los operadores del CRM. Firestore utiliza los listeners (snapshot listeners) que permiten al frontend actualizarse automáticamente cuando un documento cambia, sin necesidad de polling continuo.

Modelado de Datos para Fintech

Aunque Firestore sea NoSQL, la estructura de los datos debe ser rigurosa. Una estructura típica para un CRM Fintech podría ser:

/users/{userId}
    - profileData (Map)
    - kycStatus (String)
    /transactions/{transactionId}
        - amount (Number)
        - currency (String)
        - status (String)
        - timestamp (Timestamp)

Atención al Hotspotting: Evitad usar timestamps o ID secuenciales como claves de los documentos si prevéis escrituras masivas (>500/seg), ya que esto concentra la carga en un único rango de claves. Utilizad ID generados aleatoriamente o hash.

3. Lógica Serverless con Cloud Functions

Las Cloud Functions actúan como el pegamento entre Pub/Sub y Firestore. Cada función es un microservicio atómico con una única responsabilidad.

Ejemplo: Gestión de Cambio de Estado de Expediente

Cuando un control KYC se completa, un evento KycCompleted activa una Cloud Function. Esta función:

1. Lee el payload del evento.
2. Ejecuta una Transacción Firestore para actualizar el estado del usuario de PENDING a APPROVED.
3. Publica un nuevo evento UserActive para desbloquear las funcionalidades de trading.

4. El Desafío de la Coherencia: Idempotencia y Transacciones

Esta es la sección más crítica para un CTO o un Lead Engineer. Los sistemas distribuidos como Pub/Sub garantizan una entrega “at-least-once” (al menos una vez). Esto significa que, raramente, vuestra Cloud Function podría recibir el mismo evento de pago dos veces.

Solución: Idempotencia

Para evitar dobles cargos o estados corruptos, cada operación debe ser idempotente. He aquí cómo implementarlo en Firestore:

1. Cada evento Pub/Sub debe tener un eventId único (generado en la fuente).
2. Dentro de la transacción Firestore, verificad si el eventId ya ha sido procesado en una colección de soporte processed_events.
3. Si existe, la función termina con éxito sin hacer nada (el sistema reconoce el evento como ya gestionado).
4. Si no existe, la función ejecuta la lógica de negocio y escribe el eventId en la colección de soporte, todo atómicamente.

Este enfoque garantiza la integridad de los datos financieros incluso en caso de reintentos automáticos por parte de la infraestructura de Google.

5. Analítica Avanzada con BigQuery

Un CRM no sirve solo para gestionar, sino para entender. Los datos operativos en Firestore no están optimizados para consultas analíticas complejas (ej. “¿Cuál es la tasa de conversión media por región en el último trimestre?”).

Por esto, implementamos un pipeline de streaming hacia BigQuery. Podemos utilizar la extensión oficial “Stream Firestore to BigQuery” o una Cloud Function dedicada que escucha los cambios en Firestore e inserta los datos en tablas particionadas en BigQuery.

Esto permite al equipo de Data Science analizar los embudos de conversión y el comportamiento de los usuarios sin impactar en el rendimiento de la base de datos operativa del CRM.

Conclusiones

Construir un CRM Fintech con una arquitectura event-driven en Google Cloud ofrece ventajas innegables en términos de desacoplamiento y escalabilidad. Sin embargo, desplaza la complejidad de la gestión de la infraestructura a la gestión de la lógica de la aplicación (gestión de errores, idempotencia, consistencia eventual).

Siguiendo los patrones descritos —el uso riguroso de Pub/Sub para el buffering, Firestore para el estado en tiempo real y controles de idempotencia transaccionales— es posible crear un sistema robusto capaz de gestionar los volúmenes y la criticidad de las aplicaciones financieras modernas.

Preguntas frecuentes

Fuentes y Profundización

1. Definición y características de la Arquitectura Dirigida por Eventos (EDA)
2. Concepto de Know Your Customer (KYC) en el sector financiero
3. Banco de España: Innovación financiera y marco regulatorio Fintech
4. NIST: Definición institucional de Cloud Computing y sus modelos de servicio
5. Visión general de los servicios de Google Cloud Platform

Francesco Zinghinì

Ingeniero Electrónico con la misión de simplificar lo digital. Gracias a su formación técnica en Teoría de Sistemas, analiza software, hardware e infraestructuras de red para ofrecer guías prácticas sobre informática y telecomunicaciones. Transforma la complejidad tecnológica en soluciones al alcance de todos.

LinkedInFacebookBiografía completa →