Atomiciteit in databases: de ruggengraat van betrouwbare transacties

Atomiciteit is een kernconcept in databasesystemen. Het betekent dat een transactie ofwel volledig slaagt of helemaal niet wordt uitgevoerd. Als er halverwege iets misgaat, wordt alles teruggedraaid alsof het nooit is gebeurd.

Waarom is dit zo belangrijk, vraag je je af? Stel je voor dat je geld overmaakt van de ene bankrekening naar de andere. Je drukt op "Verzenden", de app laadt even, en dan gaat er iets mis. Het geld verdwijnt van jouw rekening, maar komt nooit aan op de andere. Nu is het gewoon… weg. Precies dat scenario is waar atomiciteit voor bedoeld is.

Misschien heb je eerder van ACID gehoord. Dat is een set van vier belangrijke eigenschappen die databases gebruiken om te voorkomen dat alles in het honderd loopt. Atomiciteit staat als eerste op die lijst, en met goede reden: zonder atomiciteit doen de rest (Consistency, Isolation en Durability) er weinig toe.

In dit artikel verkennen we wat atomiciteit betekent, hoe het werkt en waarom het zo cruciaal is in alledaagse systemen zoals bankieren en e-commerce. We kijken ook naar hoe verschillende databases het implementeren, en hoe je atomische systemen ontwerpt die goed omgaan met dingen wanneer het onvermijdelijk misgaat.

Wat is atomiciteit?

Atomiciteit betekent dat een transactie in een database ondeelbaar is. Ze wordt of volledig uitgevoerd, waarbij elke stap volgens plan verloopt, of helemaal niet. Er is geen tussenweg. Geen half afgemaakte updates, geen gedeeltelijk opgeslagen data, geen rare limbo waarin sommige dingen gelukt zijn en andere niet.

Atomiciteit in DBMS. Bron: Arpit Bhayani

Als één onderdeel van de transactie faalt, wordt alles teruggedraaid alsof er niets is gebeurd. Dat maakt atomiciteit zo'n krachtige veiligheidsmaatregel. Zonder dit loop je voortdurend het risico je data in een corrupte of inconsistente staat achter te laten, vooral in systemen waar meerdere dingen na elkaar moeten gebeuren.

Laten we een paar praktijkcases bekijken waarin atomiciteit het systeem maakt (of breekt):

Voorbeeld 1: Overschrijving tussen bankrekeningen

Stel: je maakt $100 over van je betaalrekening naar je spaarrekening.

De transactie heeft twee onderdelen:

1. $100 afschrijven van de betaalrekening
2. $100 bijschrijven op de spaarrekening

Zonder atomiciteit is het mogelijk dat stap één slaagt en stap twee faalt, bijvoorbeeld door een netwerkstoring of servercrash. Gefeliciteerd, je geld is zojuist in het luchtledige verdwenen. Atomiciteit zorgt ervoor dat ofwel beide stappen slagen, of geen van beide. Als er iets misgaat, blijft die $100 precies waar die was.

Voorbeeld 2: Voorraad en orderverwerking

Je koopt de allerlaatste limited-edition vinylplaat online. Het systeem moet:

1. De voorraad met één verlagen
2. Je bestelling bevestigen

Zonder atomiciteit kan het gebeuren dat de voorraad wordt verlaagd, maar het systeem crasht voordat de bestelling is bevestigd. Nu denkt de winkel dat het product is uitverkocht, maar niemand ontvangt de plaat. 

Hoe vaak mij dit overkomt bij online aankopen is opvallend. Ik sluit meestal het tabblad en wens hun engineers succes, maar ik koop waarschijnlijk niet meer via die website. Wie weet hoe ze met mijn persoonsgegevens omgaan als ze al niet kunnen garanderen dat hun kernfunctionaliteit rondom aankopen betrouwbaar is?

Voorbeeld 3: Vliegtuigboeksysteem

Een vlucht boeken is meestal meer dan alleen een stoel selecteren. Het systeem moet:

1. De stoel toewijzen
2. Stoelbeschikbaarheid bijwerken
3. Je kaart belasten

Als stap twee faalt en stap drie doorgaat, heb je betaald voor een stoel die niet bestaat. Niet ideaal.

Voorbeeld 4: Database en zoekindex synchroniseren

Stel dat je app de beschrijving van een product bijwerkt in de hoofd-database. Tegelijkertijd moet ook de zoekindex worden bijgewerkt zodat gebruikers het product met de nieuwe beschrijving kunnen vinden.

Als de database-update slaagt maar de index-update faalt, zien gebruikers verouderde resultaten of kunnen ze het product helemaal niet vinden.

Waarom atomiciteit ertoe doet

Dus waarom is atomiciteit zo'n big deal? 

Er zijn talloze redenen waarom een transactie onderbroken kan worden. Er kan een stroomstoring zijn, een servercrash of een netwerk-time-out halverwege. Als atomiciteit niet wordt afgedwongen, kan die transactie slechts gedeeltelijk worden uitgevoerd. Nu blijft je database achter in een ongemakkelijke staat: sommige wijzigingen gingen door, andere niet, en je hebt geen eenvoudige manier om de puinhoop ongedaan te maken.

Hier worden databugs echt verraderlijk. Gebruikers merken misschien in eerste instantie niets, maar na verloop van tijd klopt er van alles niet meer. Je analytics zien er vreemd uit, bestellingen verdwijnen, rekeningen kloppen niet, of supporttickets schieten omhoog omdat mensen niet kunnen vinden wat ze zojuist hebben opgeslagen.

Atomiciteit voorkomt dat allemaal door ervoor te zorgen dat:

• Een transactie ofwel volledig gebeurt of helemaal niet
• Het systeem zich schoon kan herstellen, zelfs als er halverwege iets faalt
• Je data consistent blijft, zelfs bij systeemcrashes of gelijktijdige toegang

Het hangt ook nauw samen met de andere ACID-eigenschappen. Zonder atomiciteit gaat consistentie overboord, omdat je geen regels kunt afdwingen als de helft van de data ontbreekt, en isolatie breekt, omdat andere gebruikers gedeeltelijke data van een onvolledige transactie kunnen zien.

Het is vooral belangrijk als je te maken hebt met:

• Transacties met meerdere stappen, waarbij de ene actie afhankelijk is van de andere.
• Updates over meerdere rijen of tabellen, waarbij gerelateerde data synchroon moet blijven.
• Gedistrubeerde systemen, waarbij delen van de transactie op verschillende machines of databases plaatsvinden.

Hoe atomiciteit in de praktijk werkt

Achter de eenvoud van "alles of niets" schuilt een verrassend verfijnd systeem. Wanneer een database een transactie uitvoert, houdt hij elke stap actief bij, bereidt deze voor en beschermt deze.

Hier is een overzicht op hoog niveau van wat er gebeurt:

De levenscyclus van een transactie

1. Begin transactie: Het systeem markeert het begin van een transactie en isoleert de aankomende wijzigingen van de rest van de database.
2. Voer bewerkingen uit: Dit omvat al je inserts, updates, deletes of welke SQL-magie je ook doet.
3. Commit of rollback: Als elke bewerking slaagt, wordt de transactie gecommit en worden de wijzigingen permanent. Als er iets faalt, wordt de hele transactie teruggedraaid.

Logging en journaling

Om atomiciteit te waarborgen, schrijven databases logs van wat er gaat gebeuren voordat het daadwerkelijk gebeurt. Deze logs worden apart opgeslagen en fungeren als een back-upplan.

Als het systeem midden in een transactie crasht, kan het naar de log verwijzen en onvolledige wijzigingen terugdraaien, voltooide wijzigingen veilig opnieuw toepassen en de database herstellen naar een schone, consistente staat.

Deze aanpak wordt ook wel Write-Ahead Logging (WAL) of journaling genoemd en is een essentieel onderdeel van crashherstel.

Rollbacks en herstel

Wanneer een transactie faalt, geeft de database niet gewoon op, maar maakt zij de wijzigingen zorgvuldig ongedaan. Aangepaste rijen worden teruggezet naar hun oorspronkelijke staat, eventuele locks die door de transactie werden vastgehouden, worden vrijgegeven en logs worden gebruikt om gedeeltelijke updates terug te draaien.

In het geval van een crash starten herstelroutines bij het opnieuw opstarten. Ze spelen logs af, lossen onafgemaakte transacties op en zorgen ervoor dat de database precies oppakt waar hij was gebleven, zonder rare halfstaten.

Performance versus atomiciteit

Niet verrassend komt dit met een prijs. Atomiciteit introduceert:

• Locking: om te voorkomen dat anderen dezelfde data midden in een transactie wijzigen
• Overhead: door logging- en rollbackmechanismen
• Deadlocks: wanneer meerdere transacties op elkaar wachten om resources vrij te geven

Daarom moet je grote transacties zorgvuldig ontwerpen. Als je te veel in één keer doet, kun je je hele systeem vertragen of in concurrentieproblemen terechtkomen.

Atomiciteit in populaire databasesystemen

Atomiciteit is een kernconcept in alle grote databases, maar de implementatie kan enigszins verschillen afhankelijk van de onderliggende storage-engine en ontwerpfilosofie. Laten we bekijken hoe PostgreSQL en MySQL (InnoDB) zorgen dat transacties correct werken.

PostgreSQL

Voordat er permanent data wordt weggeschreven, maakt PostgreSQL een write-ahead log (WAL), het register van elke voorgenomen wijziging waar we het eerder over hadden. Deze log wordt veilig opgeslagen en gebruikt als herstelplan als er tijdens de transactie iets misgaat.

Wanneer een transactie gecommit wordt, controleert PostgreSQL de WAL, bevestigt dat alle wijzigingen compleet en geldig zijn, en rondt dan de updates af. Als er halverwege iets crasht, gebruikt de database die log om onvoltooide werkzaamheden terug te draaien.

Mooi is dat dit allemaal automatisch achter de schermen gebeurt. Vanuit het perspectief van een developer is het naadloos: je schrijft een transactie en PostgreSQL garandeert atomiciteit zonder dat je de complexiteit hoeft te beheren.

Er zijn geen wijzigingen zichtbaar voor andere gebruikers totdat de transactie volledig is gecommit. Dat houdt dingen consistent en voorkomt elke "half-opgeslagen" gekkigheid in omgevingen met meerdere gebruikers.

PostgreSQL WAL. Bron: AlgoMaster

Wil je praktisch aan de slag en je eigen databases maken om transacties te testen? Bekijk dan onze PostgreSQL-cursus.

MySQL (InnoDB)

De InnoDB-storage-engine van MySQL ondersteunt ook atomische transacties, en de aanpak is gericht op zowel betrouwbaarheid als performance.

Net als PostgreSQL gebruikt InnoDB een transactielog om wijzigingen bij te houden voordat ze worden gecommit. Als er iets mislukt, wordt de log gebruikt om alles terug te draaien naar de staat van vóór de transactie. Zo sluipen er geen gedeeltelijke updates tussendoor.

Eén ding waar InnoDB bijzonder goed in is, is het groeperen van writes. Dat helpt de schijf-I/O te verminderen en verbetert de performance, terwijl de atomiciteit behouden blijft. Het gebruikt ook undo-logs om wijzigingen tijdens een rollback terug te draaien en redo-logs voor crashherstel.

Net als in PostgreSQL kun je erop vertrouwen dat de database deze mechanismen voor je afhandelt. Je hoeft geen eigen rollbackcode te schrijven.

Belangrijkste inzichten voor engineers en data-architecten

Er zijn een paar dingen om in gedachten te houden wanneer je met atomische transacties werkt in je eigen projecten. De overkoepelende gedachte is om atomiciteit als de standaard te zien, niet als luxe. Als je systemen bouwt die data op meer dan één plek tegelijk wijzigen (wat eigenlijk altijd zo is), bespaart ontwerpen met atomiciteit in gedachten je tijd, stress en mogelijk een incidentmelding om 3 uur ’s nachts. 

Kies de juiste database voor de klus

Niet alle databases gaan op dezelfde manier met atomiciteit om, en niet alle storage-engines zijn gelijk. Als atomiciteit cruciaal is voor je usecase (bijv. finance, logistiek, user state management), zorg dan dat je database volledige ACID-transacties ondersteunt. Dat is vooral relevant als je MySQL gebruikt, waar de keuze van de storage-engine telt.

Ontwerp op falen

Ga ervan uit dat dingen mis zullen gaan, want dat doen ze. Verpak bewerkingen met meerdere stappen in transacties en handel fouten goed af. Wees expliciet met je BEGIN, COMMIT, en ROLLBACK-statements, of gebruik frameworks die dit veilig onder de motorkap afhandelen.

De meeste moderne ORM’s en data access-lagen bieden ingebouwde transactiesupport. Bijvoorbeeld:

• In Node.js kun je met libraries zoals Prisma en TypeORM logica verpakken in een transaction()-aanroep die commit/rollback achter de schermen afhandelt.

• In Python biedt SQLAlchemy contextmanagers (with session.begin():) die veilige commits en rollbacks garanderen.

• In Java kun je in frameworks zoals Spring methoden annoteren met @Transactional, zodat de database alles atomisch afhandelt, zelfs over meerdere functieaanroepen heen.

Deze tools maken het veel makkelijker om standaard veilig te bouwen. Ze verkleinen het risico dat je een rollback vergeet of commitlogica verkeerd beheert, zeker wanneer je app complexer wordt.

Balanceer performance met betrouwbaarheid

Atomiciteit brengt wat overhead met zich mee, vooral in grote transacties. Hak enorme operaties waar mogelijk in stukken, vermijd het locken van volledige tabellen en houd transacties kort en gefocust. Langdurige transacties vergroten de kans op contentie, deadlocks en ontevreden gebruikers.

Begrijp afhankelijkheden en isolatie

Zoals we eerder zagen, bestaat atomiciteit niet in een vacuüm maar samen met consistentie en isolatie. Zorg dat gerelateerde wijzigingen samen plaatsvinden en denk na over hoe gelijktijdige transacties op elkaar inwerken. Gebruik isolatieniveaus die passen bij je workload zonder dingen onnodig te compliceren.

ACID-eigenschappen in DBMS. Bron: Datacamp

Test met realistische faalscenario’s

Test niet alleen je happy paths. Simuleer wat er gebeurt als je app crasht midden in een transactie, of wanneer een query een time-out krijgt. Je kunt failpoints gebruiken of databasefouten mocken om te zien hoe je systeem onder druk presteert.

Conclusie

Als je systemen bouwt waarin meerdere dingen samen moeten gebeuren, is atomiciteit niet optioneel maar essentieel. Of je nu geld verplaatst tussen rekeningen, voorraad bijwerkt of systemen synchroniseert, atomiciteit zorgt ervoor dat je data niet in een kapotte of half-afgemaakte staat belandt.

Wil je dieper gaan? Volg dan onze cursus Database Design. Je leert databases in SQL ontwerpen om data efficiënter te verwerken, op te slaan en te organiseren.

En als je interesse hebt in meer praktische artikelen en tutorials over databaseontwerp, bekijk dan onze serie over databasnormalisatie:

• Normalisatie in SQL (1NF - 5NF): een beginnersgids-tutorial
• Wat is First Normal Form (1NF)?-tutorial
• Wat is Second Normal Form (2NF)?-tutorial
• Wat is Third Normal Form (3NF)?-tutorial
• Wat is transitive dependency?-tutorial