Que sont les transactions ACID ?

Une transaction ACID est un groupe d’opérations de base de données validé comme une seule unité — atomique, cohérente, isolée et durable. L’idée précède l’acronyme : Jim Gray a défini les garanties en 1981, Härder et Reuter les ont baptisées ACID en 1983, et quarante ans plus tard, cela reste le contrat qui vous permet de déplacer de l’argent dans un logiciel sans, de temps en temps, en inventer ou en détruire une partie.

Points clés

Comment fonctionnent les transactions ACID en SQL (exemple de virement bancaire)

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 'alice';
UPDATE accounts SET balance = balance + 100 WHERE id = 'bob';

-- Crash ou erreur entre les deux UPDATE ? Le moteur fait un rollback :
-- ROLLBACK;  →  les deux modifications disparaissent ; l'argent ne peut pas s'évaporer

COMMIT;       -- ou les deux deviennent permanentes, atomiquement, durablement

Le code applicatif rencontre les mêmes garanties en plus petits paquets — des opérations atomiques sur les champs qui mettent fin à la course read-modify-write, et des lots validés ensemble :

// JavaScript / Node.js — Back4app JS SDK
// Atomicity where apps actually need it
counter.increment('sold', 1);        // atomic single-field update — no
await counter.save();                // read-modify-write race possible

// All-or-nothing batch: both rows commit, or neither does
await Parse.Object.saveAll([debitEntry, creditEntry], { transaction: true });

// Flutter / Dart — Back4app Flutter SDK
// Atomicity where apps actually need it
counter.setIncrement('sold', 1);     // atomic single-field update — no
await counter.save();                // read-modify-write race possible

// Batches group writes; atomic counters remove the classic race
await ParseObject.saveAll([debitEntry, creditEntry]);

// iOS / Swift — Back4app Swift SDK
// Atomicity where apps actually need it
var updated = counter
updated.sold = (updated.sold ?? 0) + 1
// Prefer the atomic operation over read-modify-write:
let op = counter.operation.increment("sold", by: 1)
op.save { result in
  if case .success = result { print("atomic increment committed") }
}

// Android / Kotlin — Back4app Android SDK
// Atomicity where apps actually need it
counter.increment("sold")            // atomic single-field update — no
counter.saveInBackground()           // read-modify-write race possible

// Batches group writes; atomic counters remove the classic race
ParseObject.saveAllInBackground(listOf(debitEntry, creditEntry))

Le cycle de vie d’une transaction : BEGIN, COMMIT et ROLLBACK

Les quatre propriétés, chacune par ce qui casse sans elle : l’atomicité — sans elle, des écritures partielles (le virement débité-mais-jamais-crédité). La cohérence — sans elle, des états validés qui violent vos propres règles (stock négatif, références orphelines). L’isolation — sans elle, les transactions concurrentes lisent le travail à moitié fini les unes des autres. La durabilité — sans elle, des données « validées » qu’un crash désécrit en silence. Sous le capot, trois mécanismes les assurent : des journaux d’annulation pour le rollback, le write-ahead logging pour survivre aux crashs, et le verrouillage ou MVCC pour la concurrence.

Niveaux d’isolation vs. anomalies de lecture

La matrice que les résultats de recherche n’assemblent jamais — quel niveau arrête quelle anomalie :

Traduction : une lecture sale (dirty read) voit du travail non validé ; une lecture non répétable obtient des réponses différentes en demandant deux fois ; un fantôme voit des lignes apparaître en cours de transaction. La plupart des moteurs modernes adoptent par défaut un comportement snapshot basé sur MVCC — chaque transaction lit un instantané cohérent pendant que les écrivains avancent — et c’est pourquoi « les lecteurs ne bloquent pas les écrivains » est devenu la norme plutôt que l’exception.

ACID vs. BASE — et l’homonymie de la cohérence

Une seule désambiguïsation porte toute cette comparaison : le C d’ACID et le C de CAP sont deux mots différents qui partagent la même lettre. La cohérence ACID signifie que chaque transaction préserve les règles que vous avez déclarées. La cohérence CAP signifie que tous les nœuds sont d’accord à l’instant même. Une base de données mono-nœud est pleinement ACID sans que CAP entre dans la pièce ; un système distribué choisit son trade-off CAP et ses garanties transactionnelles séparément.

Qui garantit quoi

Les transactions distribuées méritent leur note de bas de page honnête : le commit à deux phases (two-phase commit) achète l’atomicité entre nœuds au prix de la latence et d’un coordinateur bloquant, ce qui explique pourquoi les architectures microservices préfèrent de plus en plus les sagas — des séquences de transactions locales avec des rollbacks compensatoires, échangeant la cohérence immédiate contre la disponibilité. Si un workflow ne tolère réellement pas la compensation, c’est la preuve qu’il a sa place dans une seule base de données, pas réparti sur plusieurs.

Cas d’usage courants

• Mouvements d’argent. Virements, paiements sortants, grands livres — le cas canonique, et toujours le plus clair.
• Inventaire et réservation. Décrémenter le stock et confirmer la commande ensemble, ou regarder deux clients acheter le dernier siège.
• Invariants multi-lignes. Commande + lignes de commande, compte + entrée d’audit — des enregistrements qui ne sont valides que nés ensemble.
• Des compteurs bien faits. Les incréments atomiques — la plus petite dose utile d’ACID — mettent fin à la course read-modify-write sans transactions complètes.
• Le complément à cohérence à terme. Feeds, likes, analytics : explicitement routés à l’écart du coût transactionnel, à dessein.

Faut-il de l’ACID ? Matrice de décision

Le métier, c’est le routage par écriture : le checkout utilise des transactions, le compteur de vues utilise un incrément atomique, le feed tolère une seconde de dérive — une seule application, trois tarifs pour la cohérence.

Limites et trade-offs

• La coordination est le centre de coûts. Les verrous se disputent, les synchronisations du WAL frappent le disque, les retries en serializable avortent — la correction a une facture en débit, et c’est toute la raison d’être de BASE.
• Les niveaux d’isolation sont une valeur par défaut piégée. La plupart des moteurs ne sont pas en serializable par défaut ; connaissez votre niveau, sinon les anomalies que vous croyiez impossibles sont seulement improbables.
• Les transactions longues sentent mauvais. Tenir des verrous pendant le temps de réflexion de l’utilisateur ou des appels réseau transforme les garanties en contention ; gardez les transactions courtes et décisives.
• L’ACID distribué est coûteux par nature. Des tours de consensus à chaque commit — payez-le là où les invariants l’exigent, pas partout par réflexe.
• ACID ne peut pas valider vos règles à votre place. La cohérence préserve les contraintes déclarées ; les règles métier jamais encodées ne sont, fidèlement, pas appliquées.

Les transactions ACID sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Sa boîte à outils transactionnelle colle à la façon dont les apps consomment réellement ACID : chaque écriture d’un objet unique est atomique sur le moteur documentaire sous-jacent, les incréments atomiques et opérations sur tableaux mettent fin aux courses classiques sur les compteurs (les onglets de code ci-dessus), les enregistrements par lot regroupent les écritures, et les invariants en plusieurs étapes ont leur place dans Cloud Code — validés et exécutés côté serveur, où un trigger beforeSave peut refuser toute écriture qui enfreindrait les règles. La matrice de décision est intégrée : une atomicité bon marché par défaut, la coordination complète là où vous la demandez.