ACID oder BASE – so triffst du die richtige Wahl für dein System

Wenn du mit Datenbanken arbeitest, hörst du schnell die Begriffe ACID und BASE. Dahinter stecken zwei unterschiedliche Strategien, wie Systeme mit Konsistenz, Verfügbarkeit und Skalierung umgehen. Beide lösen echte Probleme, aber auf verschiedene Arten.

In diesem Beitrag zeige ich dir, was ACID und BASE bedeuten, warum sie sich in verteilten Systemen anders verhalten, und wie du für typische Szenarien die passende Entscheidung triffst. Du bekommst klare Erklärungen, einfache Beispiele und konkrete Hinweise, wann welches Modell sinnvoll ist.

Grundlagen: Worum geht es bei Konsistenzmodellen

Konsistenzmodelle legen fest, wie verlässlich Daten wirken, wenn gleichzeitig viele Benutzer und Dienste darauf zugreifen. Drei Kräfte ziehen dabei an dir: Konsistenz, Verfügbarkeit und Partitionstoleranz. In verteilten Systemen musst du je nach Ziel Prioritäten setzen. ACID priorisiert starke Konsistenz, BASE priorisiert Verfügbarkeit und Skalierung mit eventueller Konsistenz.

ACID kurz und greifbar

ACID steht für Atomicity, Consistency, Isolation, Durability:

Atomicity

Eine Transaktion passiert ganz oder gar nicht. Beim Kontotransfer wird Geld entweder von A abgebucht und B gutgeschrieben oder nichts passiert. Kein Zwischenzustand.

Consistency

Regeln und Integritätsbedingungen bleiben erhalten. Nach der Transaktion erfüllen die Daten wieder alle Constraints, z. B. Fremdschlüssel oder Saldo darf nicht negativ sein.

Isolation

Gleichzeitige Transaktionen beeinflussen sich nicht. Je nach Isolation Level (z. B. Read Committed, Repeatable Read, Serializable) verhinderst du Nebenwirkungen wie Dirty Reads.

Durability

Was bestätigt wurde, ist dauerhaft gespeichert. Ein Crash ändert das Ergebnis nicht mehr.

Wofür geeignet: Transaktionale Kernsysteme wie Banking, Buchhaltung, Bestandsführung, Buchungssysteme. Du brauchst sofort korrekte Daten, selbst wenn das System dafür weniger flexibel skaliert.

BASE kurz und greifbar

BASE steht für Basically Available, Soft state, Eventual consistency:

Basically Available

Das System antwortet meistens. Einzelne Knoten dürfen temporär ausfallen, ohne den Gesamtdienst zu stoppen.

Soft state

Zustand kann sich ohne neue Writes verändern, weil Hintergrundprozesse replizieren und abgleichen.

Eventual consistency

Alle Replikate nähern sich mit der Zeit einem gemeinsamen Zustand. Kurzfristige Abweichungen sind erlaubt.

Wofür geeignet: Systeme mit hohem Durchsatz und weltweiter Verteilung, bei denen sofortige Strenge nicht nötig ist, z. B. Social Media Likes, Produktkataloge, Streaming-Metriken, Caching.

ACID vs BASE im Alltag verstehen

Beispiel 1: Banküberweisung

Du überweist 50 Euro. ACID garantiert: Entweder minus 50 bei dir und plus 50 beim Empfänger oder gar nichts. Zwischenstände sind tabu. Genau das willst du hier.

Beispiel 2: Like-Zähler in einer App

Du drückst Like in einem U-Bahntunnel. Dein Gerät bestätigt schnell, Server A zählt hoch, Server B hinkt kurz hinterher. Nach wenigen Sekunden gleichen sich die Replikate an. BASE ist hier okay, weil eine kurzzeitige Abweichung unkritisch ist.

Konsistenzarten in einfachen Worten

• Starke Konsistenz: Nach einer Bestätigung sehen alle sofort denselben Wert.
• Eventuelle Konsistenz: Werte konvergieren mit der Zeit, kurzfristige Unterschiede sind möglich.
• Monotone Reads/Write-Your-Writes: Du siehst mindestens deine eigenen Writes oder liest nicht rückwärts. BASE-Systeme bieten oft solche abgeschwächten Garantien, um die Nutzererfahrung trotzdem verlässlich zu machen.

Wie ACID und BASE mit dem CAP-Dreieck zusammenhängen

Das CAP-Dreieck sagt: Unter Partitionen (Netzwerkausfällen) kannst du Konsistenz oder Verfügbarkeit priorisieren.

• ACID-lastige Systeme bevorzugen Konsistenz über Verfügbarkeit.
• BASE-lastige Systeme bevorzugen Verfügbarkeit und nehmen vorübergehende Inkonsistenz in Kauf.
  Beides ist legitim, die Wahl hängt von deinem Fachproblem ab.

Designentscheidungen Schritt für Schritt

1. Fachanforderung klären

Frage dich: Ist sofort korrekter Zustand geschäftskritisch oder reicht zeitnahe Korrektheit? Wenn ein Fehlbetrag oder Doppelkauf teuer wäre, spricht das für ACID. Wenn ein Like oder Produktview kurz schwankt, ist BASE meist sinnvoll.

2. Scope der Transaktion bestimmen

In einer einzigen Datenbank ist ACID trivial. Über mehrere Services wird es schwieriger. Nutze bei Microservices statt globaler 2-Phasen-Commits oft Sagas: Jeder Schritt hat Kompensation, falls später etwas fehlschlägt. So bleibst du robust ohne harte globale Locks.

3. Lese- und Schreibmuster entkoppeln

Baue Command-Query Responsibility Segregation: Schreibe streng, lies repliziert und eventuell konsistent. Für kritische Masken bietest du einen starken Leseweg an, für Dashboards reicht BASE.

4. Idempotenz und Replays vorsehen

Bei Retries darf ein Befehl keine Doppelwirkung haben. Verwende eindeutige Request-IDs oder natürliche Schlüssel, damit Wiederholungen idempotent sind. Das schützt sowohl ACID- als auch BASE-Flows.

5. Nutzerführung bedenken

Wenn Daten eventuell konsistent sind, kommuniziere das: Mini-Hinweise wie „wird synchronisiert“ oder optimistic UI, die später korrigiert, verbessern das Verständnis und senken Support.

Kleine Praxisbeispiele zum Nachbauen

ACID-Transaktion in SQL

Eine klassische Buchung mit atomarem Transfer:

BEGIN;
UPDATE konto SET saldo = saldo - 50 WHERE id = 1;
UPDATE konto SET saldo = saldo + 50 WHERE id = 2;
COMMIT;

Fällt eine Zeile aus, ROLLBACK und alles bleibt konsistent.

BASE-Style Zähler mit späterer Korrektur

Du schickst Likes an eine Message Queue. Konsumenten inkrementieren pro Shard. Ein Periodenjob gleicht Abweichungen aus, indem er Zähler gegen den Event-Log validiert. Kurzzeitig kann der Zähler variieren, langfristig konvergiert er.

Häufige Fehler und wie du sie vermeidest

• Alles muss stark konsistent sein: Das ist teuer und limitiert Skalierung. Wähle gezielt aus, wo du es wirklich brauchst.
• Eventual consistency ohne UX-Hinweise: Nutzer sind verwirrt. Zeige Sync-Status und verhindere kritische Aktionen, bis Daten stabil sind.
• Verteilte ACID-Transaktionen erzwingen: Globale Locks über viele Services sind fragil. Prüfe Sagas oder Outbox-Pattern.
• Keine Idempotenz: Wiederholte Requests verursachen Doppelbuchungen. Plane Idempotency Keys von Anfang an ein.

Entscheidungsleitfaden in einem Satz pro Fall

• Zahlungen, Lager, Buchungen: ACID für Kernschritte, optional BASE für Berichte.
• Social Features, Zähler, Feeds: BASE für Durchsatz, punktuell starke Konsistenz für kritische Updates.
• Kataloge, Suchen, Caches: BASE mit schneller Replikation und TTL, Rückgriff auf starke Quelle bei Unsicherheit.
• Compliance-relevante Audits: ACID oder unveränderliche Event-Logs mit strenger Auswertung.

Fazit

ACID und BASE sind keine Gegner, sondern Werkzeuge für unterschiedliche Ziele. ACID gibt dir sofort korrekte, transaktionale Sicherheit. BASE gibt dir Skalierung, Verfügbarkeit und Tempo mit eventueller Konsistenz. Wenn du deine Fachlogik, Lastprofile und UX kennst, kannst du beide Modelle klug kombinieren: streng dort, wo es zählen muss, flexibel dort, wo es dir Geschwindigkeit bringt.