Was ist ein Concurrency-Problem?

Ein Concurrency-Problem, auch Race Condition genannt, entsteht, wenn zwei oder mehr Prozesse gleichzeitig auf denselben Datensatz zugreifen und ihn verändern wollen, ohne voneinander zu wissen. Das Ergebnis ist unvorhersehbar und meistens falsch.

Das klassische E-Commerce-Beispiel: Du hast 1 Stück auf Lager. Zwei Kunden kaufen dieses Artikel gleichzeitig in zwei verschiedenen Kanälen. Beide Bestellprozesse lesen den Bestand: 1. Beide prüfen: 1 ist größer als 0, also Kauf möglich. Beide verarbeiten die Bestellung und reduzieren den Bestand auf 0. Du hast zwei Bestellungen für ein Produkt verkauft, das einmal vorhanden ist. Überverkauf ist das Ergebnis.

Wie entstehen Concurrency-Probleme?

Sie entstehen immer dann, wenn mehrere Prozesse oder Threads ohne Koordination auf gemeinsame Ressourcen zugreifen. In verteilten Systemen, wie einem Omnichannel-Setup mit mehreren Verkaufskanälen und mehreren Backend-Systemen, ist das schwieriger zu vermeiden als in einem einzelnen System.

Auch innerhalb eines einzigen Systems kann es passieren: Wenn zwei gleichzeitige API-Anfragen dieselbe Bestellung verarbeiten wollen, können sie sich gegenseitig überschreiben.

Wie löst du Concurrency-Probleme?

Optimistic Locking: Beim Lesen eines Datensatzes wird ein Versions-Zähler oder Timestamp mitgelesen. Beim Schreiben wird geprüft, ob der Datensatz in der Zwischenzeit von jemandem anderen geändert wurde (Versions-Zähler hat sich erhöht). Wenn ja, wird die Operation abgebrochen und der Prozess muss neu starten mit den aktualisierten Daten.

Pessimistic Locking (Datenbanksperre): Beim Lesen wird der Datensatz sofort gesperrt, sodass kein anderer Prozess ihn gleichzeitig lesen und ändern kann. Sicherer, aber bei hohem Durchsatz ein Performance-Flaschenhals.

Atomare Operationen: Statt “Lese Bestand, prüfe, vermindere” in drei Schritten wird eine atomare SQL-Operation verwendet: UPDATE inventory SET stock = stock - 1 WHERE id = X AND stock > 0. Diese Operation schlägt atomar fehl, wenn der Bestand bereits 0 ist.

Queue-basierte Serialisierung: Alle Bestandsänderungen für einen Artikel werden in einer Queue nacheinander verarbeitet, nicht parallel. Kein Concurrency-Problem möglich, weil nie zwei Prozesse gleichzeitig denselben Artikel ändern.

Concurrency-Probleme sind in E-Commerce-Projekten mit Multikanal-Setup ein ernstes Thema. Bei der Softwareentwicklung und Automation wählen wir die geeignete Strategie je nach Anforderung. Beim Termin können wir prüfen, ob dein aktuelles Setup gegen Überverkauf abgesichert ist.