</>

PostgreSQL dans vos applications

Avancé

Connexions et pools, transactions côté code, patrons de fiabilité (outbox, idempotence), multi-tenance et tests avec de vraies bases.

  1. 01

    Se connecter depuis .NET, Rust et le reste

    Quel que soit le langage, le schéma est le même : une chaîne de connexion, un pool de connexions, des requêtes paramétrées.

  2. 02

    Transactions dans le code

    Une transaction doit être courte, cohérente et réessayable.

  3. 03

    Le patron Outbox : fiabiliser les événements

    Problème : après avoir enregistré une commande, il faut publier un événement (Kafka, RabbitMQ). Si l'application plante entre les deux, la commande existe sans événement (ou l'inverse). Il n'existe pas de transaction commune entre la base et le broker.

  4. 04

    Idempotence et exécutions multiples

    Dans un système distribué, tout message et toute requête peuvent être livrés plus d'une fois : les traitements doivent l'accepter.

  5. 05

    Multi-tenance : un schéma, plusieurs clients

    Une application SaaS doit isoler les données de chaque client (« locataire ») : trois grandes approches.

  6. 06

    Tester avec une vraie base

    Une base simulée ne reproduit ni les contraintes, ni les verrous, ni le SQL réel : pour le code d'accès aux données, testez avec PostgreSQL lui-même.