ADR-0014 — Schémas PostgreSQL séparés par microservice

Status : Accepted Date : 2026-02 (rétroactif) Deciders : équipe plateforme Nex Tickets : —

Contexte

Une plateforme à 11 microservices doit décider de la stratégie de persistance : une base par service ? une base unique avec schémas ? un schéma global ?

Contraintes :

• Coût opérationnel (provisioning, monitoring) — un cluster RDS par service serait disproportionné.
• Isolation logique entre domaines (auth ne doit pas écrire dans ledger).
• Migration et propriété claire des tables.
• Audit : qui peut lire quoi.

Décision

1. Une seule instance RDS PostgreSQL par environnement, mais un schéma logique par service (auth, ledger, customer, notification, etc.).
2. Chaque service ne se connecte qu’à son schéma via un utilisateur PostgreSQL dédié, avec privilèges restreints (USAGE + SELECT/INSERT/UPDATE/DELETE sur son schéma uniquement).
3. Pas de jointures cross-schema : si le service A a besoin d’une info du service B, il appelle l’API du service B.
4. Migrations : gérées localement par chaque service via TypeORM (197 migrations totales toutes versions confondues, distribuées par service).
5. Pas d’ORM cross-service (infrastructure/prisma/schema.prisma est uniquement de l’introspection — pas runtime).

Conséquences

Positives

• Isolation logique forte (RBAC PostgreSQL par schéma).
• Coût RDS unique (un seul cluster à scaler).
• Pas de tentation de jointure cross-domain qui couplerait deux services.
• Migrations indépendantes par service (un service peut migrer sans bloquer les autres).
• Convention auditable : un audit lit immédiatement « ce service écrit dans ce schéma uniquement ».

Négatives / risques

• Pas d’isolation au niveau panne / charge / backup différencié (un service qui sature la DB impacte les autres). Mitigation : monitoring par service, séparation possible à terme.
• Pas de schéma global central — l’ERD se construit en agrégeant les schémas (à produire dans /architecture/c4-components/).
• Pas de runner de migration centralisé — chaque service migre indépendamment, complexité de coordination si un changement de contrat impacte plusieurs services.

Alternatives écartées

• Une RDS par service — coût et complexité opérationnelle prohibitifs.
• Un schéma unique partagé — couplage maximum, perte d’isolation.
• Migration vers NoSQL — pas adapté aux flux monétaires (besoin de transactions ACID strictes).

Suivi

• Vars Doppler critiques : NOTIFICATIONS_SCHEMA=notification (sinon OTP silently dropped). Cf. ADR-0008.
• Schemas par service documentés dans chaque page /services/<service>/data-model (cf. /services/auth/overview).
• Convention ledger : agent simple = (userId, 'user'), master = (organizationId, 'corporate'). Le personId n’est jamais l’entity ledger.