Communication inter-services

Patterns

ADB combine trois patterns de communication :

1. HTTP synchrone entre microservices Java, via WebClient réactif et l'enum FQDN.
2. Événements asynchrones via AWS SQS / SNS (et historiquement RabbitMQ pour adb-graph).
3. Edge BFF sur Cloudflare Workers (adb-web) pour les requêtes côté navigateur.

1. HTTP synchrone — l'enum FQDN

Tous les services Java déclarent leurs cibles via une enum centralisée dans adb/adb-common/src/main/java/fr/lifeconnect/adb/client/FQDN.java.

La résolution DNS est assurée par Kubernetes : chaque chart Helm (adb-charts/charts/services/) crée un Service portant le nom du microservice, ce qui rend http://adb-persons directement résolvable depuis n'importe quel autre pod.

Matrice des appels sortants

flowchart LR
    persons[adb-persons]
    parts[adb-parts]
    contracts[adb-contracts]
    accounting[adb-accounting]
    files[adb-files]
    utilities[adb-utilities]
    aggregates[adb-aggregates]
    views[adb-views]
    reports[adb-reports]

    persons --> files

    parts --> persons
    parts --> contracts
    parts --> utilities

    contracts --> persons
    contracts --> parts
    contracts --> files
    contracts --> accounting
    contracts --> utilities

    accounting --> persons
    accounting --> parts
    accounting --> contracts
    accounting --> files
    accounting --> utilities

    aggregates --> persons
    aggregates --> parts
    aggregates --> contracts
    aggregates --> files
    aggregates --> utilities

    views --> persons
    views --> parts
    views --> contracts
    views --> files

    reports --> aggregates

adb-utilities et adb-files n'appellent aucun autre service (ils sont feuilles).

2. Gateway — adb/proxy (Nginx)

Le module proxy du projet parent expose une API Gateway Nginx qui route les requêtes externes vers les services. Les chemins suivent le pattern /<service>/... :

• /persons/* → adb-persons
• /parts/* → adb-parts
• /contracts/* → adb-contracts
• /accounting/* → adb-accounting
• /files/* → adb-files
• /utilities/* → adb-utilities
• /aggregates/* → adb-aggregates
• /view/* → adb-views (note : /view au singulier)
• /reports/* → adb-reports
• /tickets/* → adb-tickets
• /notes/* → ⚠ redirige vers adb-tickets (notes déprécié)

L'authentification Keycloak est validée par chaque service (resource server OAuth2), pas par la gateway.

3. BFF Cloudflare — adb-web/apps/bff

Pour les nouveaux flux frontend, adb-web intercale un BFF (Backend-For-Frontend) sur Cloudflare Workers, écrit en Hono. Ses responsabilités :

• Terminer l'authentification à l'edge (validation JWT Keycloak).
• Cacher les lectures idempotentes (KV namespace, prévu).
• Rate-limiter par utilisateur (Durable Objects, prévu).
• Fan-out vers les services Java via un Cloudflare Tunnel (secret ADB_TUNNEL_TOKEN, upstream ADB_UPSTREAM_URL).

sequenceDiagram
    participant U as Navigateur
    participant UI as adb-web/ui (Worker)
    participant BFF as adb-web/bff (Worker)
    participant T as Cloudflare Tunnel
    participant GW as adb/proxy (Nginx)
    participant S as Microservice Java

    U->>UI: GET /index.html
    UI-->>U: SPA + assets
    U->>BFF: GET /api/contracts (Bearer JWT)
    BFF->>BFF: Vérifie JWT, lit cache KV
    alt Cache miss
        BFF->>T: HTTPS via tunnel
        T->>GW: HTTP interne
        GW->>S: GET /contracts
        S-->>GW: 200 JSON
        GW-->>T: 200 JSON
        T-->>BFF: 200 JSON
        BFF->>BFF: Met en cache
    end
    BFF-->>U: 200 JSON

À ce jour seul le endpoint /healthz est implémenté dans apps/bff/src/index.ts ; les routes métier sont à monter.

4. Événements asynchrones — AWS SQS / SNS

Les services émettent des événements de modification (création / mise à jour / suppression) sur des topics SNS, consommés par les services intéressés via queues SQS (avec DLQ).

Producteurs / consommateurs principaux

Le module partagé adb-messaging (sous adb/) abstrait les SnsTemplate et SqsListener via Spring Cloud AWS 3.0.4. Région : eu-west-1.

Schéma événementiel

flowchart LR
    persons[adb-persons] -.->|onPerson*| sns((SNS))
    parts[adb-parts] -.->|onPart*<br/>onCharge*| sns
    contracts[adb-contracts] -.->|onContract*<br/>onDirectDebitProcessed| sns
    accounting[adb-accounting] -.->|onAccounting*<br/>onPayment*| sns
    files[adb-files] -.->|onFileUploaded<br/>onFileMetaDataModified| sns
    utilities[adb-utilities] -.->|onIndexPublished| sns
    tickets[adb-tickets] -.->|onTicket*| sns

    sns --> q1[SQS adb-contracts]
    sns --> q2[SQS adb-accounting]
    sns --> q3[SQS adb-views]

    q1 --> contracts2[adb-contracts]
    q2 --> accounting2[adb-accounting]
    q3 --> views[adb-views]

adb-views est le plus gros consommateur : il maintient des projections dénormalisées pour les dashboards et écoute 8 queues SQS simultanément.

5. Module RabbitMQ historique — adb-graph

Le service hors-monorepo adb-graph consomme historiquement via RabbitMQ (et non SQS) :

• Exchanges : adb-persons-x, adb-tickets-x (headers exchange)
• Queues consommées : persons.graph, parts.graph, contracts.graph, tickets.graph
• Dead-letter exchange : adb-graph-dlx

Configuration documentée dans adb-charts/mq.md. La cohabitation SQS / RabbitMQ est un héritage technique.

Récapitulatif des dépendances de chaque service

Voir la fiche individuelle de chaque service pour la liste exacte des FQDN appelés et des queues consommées.