perf: Checkout haelt gleichzeitigem Andrang stand

Ausgangsfrage: Was passiert, wenn 20 oder 100 Leute zugleich bestellen?
20 waren unproblematisch, 100 nicht. Drei Engpaesse, alle im Checkout.

1. Serialisierungskonflikte landeten ungefiltert bei der Kundschaft

Die Bestellanlage laeuft unter "Serializable". Bricht die Datenbank eine
von zwei widerspruechlichen Transaktionen ab (P2034), ist das die
VORGESEHENE Antwort auf Gleichzeitigkeit und kein Sachfehler — erwartet
wird, dass der Aufrufer es noch einmal versucht. Genau das fehlte: der
Abbruch wurde direkt als 409 durchgereicht ("bitte in ein paar Sekunden
erneut versuchen"). Weil alle Bestellungen desselben Produkts auf
dieselbe Lagerbestandszeile zugreifen, sind solche Konflikte bei Andrang
der Normalfall — ein Teil der Kundschaft haette ausgerechnet im Moment
der Kaufentscheidung eine Fehlermeldung bekommen.

Jetzt bis zu vier Versuche mit wachsender, zufaellig gestreuter
Wartezeit. Ohne den Zufallsanteil starten alle abgebrochenen Anfragen
gleichzeitig neu und kollidieren wieder. Wiederholt wird ausschliesslich
dieser Fehlerfall: "ausverkauft" und "Gutschein aufgebraucht" sind
Sachentscheidungen und faenden beim zweiten Versuch dasselbe vor.

2. Zu enger Verbindungspool, zu knappe Transaktionsfristen

Der Postgres-Adapter lief mit der Voreinstellung von node-postgres: 10
Verbindungen. Eine Bestellung haelt ihre Verbindung ueber die gesamte
Transaktion, und Prisma gibt einer Transaktion nur 2 Sekunden, um
ueberhaupt eine zu bekommen (maxWait), sowie 5 Sekunden zum Ausfuehren.
Sind alle zehn belegt, scheitern weitere Checkouts nicht an der Sache,
sondern am Warten.

Pool auf 20 (PostgreSQL erlaubt voreingestellt 100 Verbindungen, daneben
brauchen CronJob, Sicherung und Konsole noch welche; die Anwendung laeuft
mit einer Instanz). maxWait 10s, timeout 15s — Puffer fuer die
Warteschlange, nicht fuer lange Rechnungen. Dazu eine Zeitgrenze beim
Holen einer Verbindung, damit sich unter Last nichts mehr lautlos
aufstaut.

Der MariaDB-Zweig bleibt unveraendert: sein Adapter nimmt entweder die
Verbindungszeichenkette ODER ein Einstellungsobjekt, nicht beides.
Produktiv laeuft PostgreSQL.

3. Drei Regressionstests

Wiederholung fuehrt zum Erfolg, nach vier Versuchen wird aufgegeben, und
bei "ausverkauft" wird NICHT wiederholt.

tsc: 0 Fehler. vitest: 336/336 gruen (zuvor 333). eslint: 0 Warnungen.
"next build" laeuft durch.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

src/app/api/checkout/route.test.ts

@@ -10,6 +10,7 @@
  * ohne dass irgendwo ein Fehler sichtbar wurde.
  */
 import { describe, test, expect, beforeEach, vi } from "vitest";
+import { Prisma } from "@/generated/prisma/client";
 
 const sessionsCreate = vi.fn();
 const sessionsExpire = vi.fn();
@@ -215,6 +216,58 @@ describe("Checkout-Route", () => {
     });
   });
 
+  describe("Wenn viele gleichzeitig bestellen", () => {
+    /**
+     * Bei "Serializable" bricht die Datenbank eine von zwei widerspruechlichen
+     * Transaktionen ab (P2034). Das ist die vorgesehene Antwort auf
+     * Gleichzeitigkeit, kein Sachfehler — und weil alle Bestellungen desselben
+     * Produkts auf dieselbe Bestandszeile zugreifen, ist das bei Andrang der
+     * Normalfall. Frueher landete jeder dieser Abbrueche als Fehlermeldung bei
+     * der Kundschaft.
+     */
+    function serializationConflict(): Error {
+      return new Prisma.PrismaClientKnownRequestError("could not serialize access", {
+        code: "P2034",
+        clientVersion: "7",
+      });
+    }
+
+    test("wiederholt die Bestellanlage und kommt durch", async () => {
+      const runTransaction = async (arg: unknown) =>
+        typeof arg === "function" ? (arg as (tx: typeof db) => unknown)(db) : arg;
+      db.$transaction
+        .mockRejectedValueOnce(serializationConflict())
+        .mockRejectedValueOnce(serializationConflict())
+        .mockImplementation(runTransaction);
+
+      const response = await post();
+
+      expect(response.status).toBe(200);
+      expect(db.$transaction).toHaveBeenCalledTimes(3);
+      expect(sessionsCreate).toHaveBeenCalledOnce();
+    });
+
+    test("gibt nach vier vergeblichen Versuchen auf, statt endlos zu wiederholen", async () => {
+      db.$transaction.mockRejectedValue(serializationConflict());
+
+      const response = await post();
+
+      expect(response.status).toBe(409);
+      expect(db.$transaction).toHaveBeenCalledTimes(4);
+    });
+
+    test("wiederholt NICHT, wenn die Ware schlicht ausverkauft ist", async () => {
+      // Eine Sachentscheidung faende beim zweiten Versuch dasselbe Ergebnis
+      // vor — die Wiederholung wuerde die Antwort nur verzoegern.
+      db.inventory.updateMany.mockResolvedValue({ count: 0 });
+
+      const response = await post();
+
+      expect(response.status).toBe(409);
+      expect(db.$transaction).toHaveBeenCalledOnce();
+    });
+  });
+
   describe("Wenn Stripe nicht mitspielt", () => {
     test("loest die Bestellung auf und meldet ehrlich, dass nichts abgebucht wurde", async () => {
       // Regression: frueher blieb die Bestellung als "NEU" ohne Sitzungs-ID