În peisajul financiar actual, viteza și fiabilitatea nu sunt simple funcționalități, ci cerințe de conformitate. Proiectarea unui sistem de gestionare a clienților (CRM) pentru sectorul Fintech necesită o schimbare de paradigmă față de sistemele monolitice tradiționale bazate pe baze de date relaționale și apeluri sincrone. În acest ghid tehnic, bazat pe experiența de dezvoltare a sistemului BOMA, vom explora modul în care o arhitectură event-driven pe Google Cloud Platform (GCP) poate rezolva provocările de scalabilitate, coerență și reactivitate tipice sectorului.

De ce o Arhitectură Event-Driven în Fintech?

Un CRM Fintech nu se limitează la stocarea datelor anagrafice. Trebuie să reacționeze în timp real la depuneri, schimbări de stare KYC (Know Your Customer), fluctuații ale pieței și interacțiuni ale utilizatorului. O abordare tradițională Request/Response (HTTP sincron) creează o cuplare strânsă între servicii, ducând la blocaje și potențiale eșecuri în lanț.

L’arhitectura event-driven (EDA) inversează acest model. În loc ca serviciile să se apeleze direct, componentele emit “evenimente” (fapte întâmplate, cum ar fi PaymentReceived sau LeadCreated) care sunt consumate asincron de alte servicii. Conform documentației Google Cloud Architecture, acest model îmbunătățește drastic reziliența și scalabilitatea sistemului.

Stiva Tehnologică GCP: Cazul BOMA

Pentru proiectul BOMA, alegerea stivei tehnologice s-a îndreptat către servicii gestionate serverless pentru a minimiza costurile operaționale și a maximiza scalabilitatea:

• Google Pub/Sub: Coloana vertebrală de mesagerie pentru ingestia și distribuția evenimentelor.
• Cloud Functions (2nd Gen): Stratul de calcul pentru executarea logicii de business ca răspuns la evenimente.
• Firestore: Bază de date NoSQL documentară pentru starea aplicației și actualizări în timp real.
• BigQuery: Data warehouse pentru analiza istorică și rapoartele de conformitate.

1. Decuplarea cu Google Pub/Sub

Inima arhitecturii este Google Pub/Sub. Fiecare acțiune semnificativă în CRM este publicată ca mesaj pe un Topic specific.

Model de Implementare

Să ne imaginăm fluxul unui utilizator nou care se înregistrează:

1. Frontend-ul apelează un API Gateway.
2. API-ul publică un eveniment pe topicul user-onboarding.
3. Pub/Sub garantează persistența mesajului și răspunde imediat clientului (latență scăzută).

În acest moment, diverse Subscription activează workeri independenți:

• Sub A (CRM Core): Creează profilul în Firestore.
• Sub B (Compliance): Inițiază verificările anti-spălare de bani (AML) prin furnizor extern.
• Sub C (Notification): Trimite email-ul de bun venit.

Best Practice Tehnic: În Fintech, ordinea evenimentelor este critică (nu poți retrage fonduri înainte de a le fi depus). Utilizăm Ordering Keys din Pub/Sub (ex. ID-ul utilizatorului) pentru a garanta că mesajele referitoare la același client sunt procesate în ordine secvențială, menținând totodată scalabilitatea paralelă pe utilizatori diferiți.

2. Firestore: Bază de Date Documentară și Real-Time

Alegerea Firestore față de Cloud SQL este dictată de necesitatea actualizărilor în timp real pe dashboard-ul operatorilor CRM. Firestore utilizează listeneri (snapshot listeners) care permit frontend-ului să se actualizeze automat când un document se schimbă, fără necesitatea unui polling continuu.

Modelarea Datelor pentru Fintech

Deși Firestore este NoSQL, structura datelor trebuie să fie riguroasă. O structură tipică pentru un CRM Fintech ar putea fi:

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

Atenție la Hotspotting: Evitați utilizarea timestamp-urilor sau a ID-urilor secvențiale ca chei ale documentelor dacă preconizați scrieri masive (>500/sec), deoarece acest lucru concentrează sarcina pe un singur interval de chei. Utilizați ID-uri generate aleatoriu sau hash-uri.

3. Logică Serverless cu Cloud Functions

Cloud Functions acționează ca liant între Pub/Sub și Firestore. Fiecare funcție este un microserviciu atomic cu o singură responsabilitate.

Exemplu: Gestionarea Schimbării Stării Dosarului

Când un control KYC este finalizat, un eveniment KycCompleted activează o Cloud Function. Această funcție:

1. Citește payload-ul evenimentului.
2. Execută o Tranzacție Firestore pentru a actualiza starea utilizatorului din PENDING în APPROVED.
3. Publică un nou eveniment UserActive pentru a debloca funcționalitățile de tranzacționare.

4. Provocarea Coerenței: Idempotență și Tranzacții

Aceasta este secțiunea cea mai critică pentru un CTO sau un Lead Engineer. Sistemele distribuite precum Pub/Sub garantează o livrare “at-least-once” (cel puțin o dată). Aceasta înseamnă că, rareori, Cloud Function-ul vostru ar putea primi același eveniment de plată de două ori.

Soluție: Idempotență

Pentru a evita debitările duble sau stările corupte, fiecare operațiune trebuie să fie idempotentă. Iată cum se implementează în Firestore:

1. Fiecare eveniment Pub/Sub trebuie să aibă un eventId unic (generat la sursă).
2. În interiorul tranzacției Firestore, verificați dacă eventId a fost deja procesat într-o colecție de suport processed_events.
3. Dacă există, funcția se termină cu succes fără a face nimic (sistemul recunoaște evenimentul ca fiind deja gestionat).
4. Dacă nu există, funcția execută logica de business și scrie eventId în colecția de suport, totul atomic.

Această abordare garantează integritatea datelor financiare chiar și în cazul reîncercărilor automate din partea infrastructurii Google.

5. Analiză Avansată cu BigQuery

Un CRM nu servește doar la gestionare, ci și la înțelegere. Datele operaționale din Firestore nu sunt optimizate pentru interogări analitice complexe (ex. “Care este rata medie de conversie pe regiune în ultimul trimestru?”).

Pentru aceasta, implementăm un pipeline de streaming către BigQuery. Putem utiliza extensia oficială “Stream Firestore to BigQuery” sau o Cloud Function dedicată care ascultă schimbările din Firestore și introduce datele în tabele partiționate în BigQuery.

Acest lucru permite echipei de Data Science să analizeze pâlniile de conversie și comportamentul utilizatorilor fără a impacta performanța bazei de date operaționale a CRM-ului.

Concluzii

Construirea unui CRM Fintech cu o arhitectură event-driven pe Google Cloud oferă avantaje incontestabile în termeni de decuplare și scalabilitate. Totuși, mută complexitatea de la gestionarea infrastructurii la gestionarea logicii aplicative (gestionarea erorilor, idempotență, consistență eventuală).

Urmând modelele descrise — utilizarea riguroasă a Pub/Sub pentru buffering, Firestore pentru starea în timp real și controale de idempotență tranzacționale — este posibil să creați un sistem robust capabil să gestioneze volumele și criticitatea aplicațiilor financiare moderne.

Întrebări frecvente