ACID : Atomicity, Consistency, Isolation, Durability
Infrastructure
ACID : Atomicity, Consistency, Isolation, Durability. « Atomicité, cohérence, isolation, durabilité », par analogie avec un virement bancaire qui quitte un compte et arrive sur l'autre en entier, ou ne part pas du tout.
Atomicité et cohérence : Une transaction s'applique entièrement ou pas du tout, et fait passer la base d'un état valide à un autre état valide selon ses contraintes. Le « presque fait » n'existe pas, ce qui distingue une base de données d'une liste de résolutions du Nouvel An.
Isolation : Des transactions concurrentes ne doivent pas se marcher dessus. Les niveaux d'isolation (lecture validée, lecture répétable, sérialisable) échangent de la rigueur contre du débit ; le niveau par défaut d'un moteur est rarement le plus strict.
Durabilité : Une transaction validée survit à une panne. Elle repose en général sur un journal écrit avant les données (WAL) et vidé sur disque avant de confirmer.
Le prix des microservices : Découper un système en services casse la transaction unique : il faut alors des compensations et une cohérence à terme. On gagne l'indépendance, on perd la tranquillité.
Ce qui arrive si on s'en passe
Sans garanties ACID, une opération interrompue laisse des écritures partielles : un débit sans crédit, un compte créé sans ses droits, un droit retiré d'un côté mais pas de l'autre. Les accès concurrents ouvrent des situations de concurrence exploitables : deux requêtes simultanées peuvent passer le même contrôle de solde ou de quota avant que l'une ne l'ait mis à jour, et un attaquant qui envoie ses requêtes en rafale obtient deux fois ce qui ne devait être accordé qu'une fois. Sans durabilité, une confirmation donnée à l'utilisateur peut disparaître au redémarrage, y compris une révocation ou une modification de mot de passe.
Explication de la marmotte
Quand on achète une place de cinéma en ligne, plusieurs choses doivent se passer ensemble : l'argent quitte notre compte, la place est réservée, le billet est créé. Ces quatre règles garantissent qu'une base de données ne s'arrête jamais à moitié. Soit tout se fait, soit rien ne se fait. Deux personnes qui achètent la dernière place en même temps ne l'obtiennent pas toutes les deux. Et une fois l'achat confirmé, il n'est pas perdu même si le serveur tombe en panne juste après. Sans ces règles, on pourrait payer sans avoir de place.
Où ce terme est utilisé
- JavaScript et SQL côté web, ce qu'il faut savoir des deux langages (2 occurrences)
- Monolithe ou microservices : choisir sans se mentir (1 occurrence)