Bergaz Lebensmittel

Der Verkauf lief über Telefon und Nachrichten; Bestand, Bestellungen und Zahlungen wurden nicht an einer Stelle geführt. Das Schwierige an einer E-Commerce-Plattform ist nicht die Storefront, sondern die Konsistenz zwischen Zahlung und Bestand: Sendet der Zahlungsanbieter denselben Callback erneut, greifen zwei Kunden gleichzeitig nach der letzten Einheit oder bricht eine Zahlung mittendrin ab, laufen Bestand und Bestellung auseinander. Dieses Auseinanderlaufen geschieht lautlos — niemand sieht einen Fehler, die Zahlen stimmen einfach nicht mehr.

Zwei Seiten. Der Käufer: Endkunde auf der Suche nach Käse mit geschützter geografischer Herkunft; wählt eine Gewichts- und Verpackungsvariante, will sehen, wie weit die Versandkostenschwelle noch entfernt ist, und sucht beim 3D-Secure-Schritt nach Sicherheit. Das Unternehmen: Die Rolle ADMIN verwaltet Produkte, Bestand, Bestellungen und Retouren; die Rolle SALES sieht ausschließlich die Verkaufsseite und erreicht den Rest des Systems nicht.

Alleiniger Entwickler. Datenmodell, Zahlungs- und Versandintegrationen, das Bestandsbewegungsjournal, das Verwaltungs- und das Verkaufspanel, die Hintergrund-Jobwarteschlange, die Sicherheitshärtung und das Vercel-Deployment.

Next.js 16 App Router mit Neon PostgreSQL und Prisma. Der Schreibpfad ist Server Action → Zod-Validierung → Prisma-Transaktion. Der Zahlungsablauf hat fünf Schritte: Warenkorbprüfung (Bestand und Preis werden serverseitig erneut geprüft), Initialisierung von iyzico 3D Secure, Weiterleitung zur Bankverifizierung, Callback-Verarbeitung und Abschluss der Bestellung. Der Bestelldatensatz, die Bestandsminderung und der Eintrag der Bestandsbewegung werden in einer einzigen Transaktion geschrieben. Versand- und E-Mail-Aufgaben gehen in eine Hintergrund-Jobwarteschlange. Bilder liegen in Vercel Blob. Die Codeseite ist launch-ready; der Hauptzweig läuft auf Vercel als staging-ähnliche Produktion — da die produktiven iyzico- und Versand-Zugangsdaten ein operativer Cutover-Schritt sind, arbeitet der Zahlungsablauf derzeit gegen einen Mock-Anbieter.

1. 01

   Insert-first-Idempotenz beim Zahlungs-Callback

   Der Zahlungsanbieter kann denselben Callback erneut senden. Erst zu lesen, ob die Bestellung bereits bezahlt ist, und dann zu schreiben, ließ zwischen zwei gleichzeitigen Callbacks eine Race Condition offen. Das Callback-Token wird nun zuerst in eine Log-Tabelle mit Unique-Constraint geschrieben; der zweite Callback scheitert an diesem Schreibvorgang und wird nie verarbeitet.

   KompromissJeder Callback — auch die fehlgeschlagenen — schreibt eine Zeile; die Tabelle wächst fortlaufend und benötigt einen eigenen Aufräum-Job. Zudem muss ein eigener Codepfad mitgeführt werden, der eine Constraint-Verletzung nicht als Fehler, sondern als "bereits verarbeitet" liest.

2. 02

   Bestandsminderung und Bestellanlage in derselben Transaktion

   Zwischen Bestandsprüfung und Bestandsminderung konnte eine andere Bestellung die letzte Einheit übernehmen. Lesen, Prüfen, Bestellanlage, Bestandsminderung und der Eintrag der Bestandsbewegung wurden in eine einzige Transaktion zusammengeführt; scheitert eine Zahlung, laufen Bestandswiederherstellung und Stornierung auf demselben Weg in einer Transaktion.

   KompromissDie Transaktion hält die betroffenen Variantenzeilen über den gesamten Zahlungsabschluss; gleichzeitige Bestellungen desselben Produkts reihen sich dahinter ein. In einem Lastmoment ist das eine unmittelbare Verzögerung für den wartenden Kunden.

3. 03

   Geschlossene Allowlist für den Bild-Upload-Ordner

   Der Name des Upload-Ordners kam aus einer Administratoreingabe; offen gelassen waren Path Traversal und willkürliche Ordnerwucherung möglich. Die sechs zugelassenen Ordner sind als feste Menge im Code definiert, jeder Wert außerhalb löst einen Fehler aus.

   KompromissEinen neuen Ordner anzulegen erfordert nun eine Codeänderung und ein Deployment; über das Panel ist es nicht möglich. Flexibilität auf der Inhaltsseite wurde bewusst gegen eine kleinere Angriffsfläche eingetauscht.

4. 04

   Turnstile an allen anonymen Schreib-Endpunkten, nicht nur beim Login

   Bot-Traffic bedeutet nicht nur Login-Versuche; Registrierung, Produktbewertungen, Kontaktformular, Newsletter-Anmeldung und Bestellabfrage sind ebenfalls Ziele. Die Verifizierung wird an all diesen Endpunkten serverseitig geprüft.

   KompromissAlle diese Formulare hängen nun von einem Drittanbieter-Skript ab; lädt es nicht, lässt sich das Formular nicht absenden. Jede Absendung verursacht zudem die Kosten einer zusätzlichen Verifizierungsanfrage.

Prisma hält Beziehungen und Migrationshistorie über ein Schema mit 31 Modellen nachvollziehbar, und die auf der Zahlungs- und Bestandsseite benötigte Unterstützung für mehrteilige Transaktionen ist bereits eingebaut. Neon PostgreSQL bleibt im selben Serverless-Modell wie das Deployment. Vercel Blob hält Bilder aus Repository und Datenbank heraus; die Bildoptimierung läuft über ein Remote Pattern. Der Rate Limiter liegt in der Datenbank statt im Speicher — unter Serverless machte es die Begrenzung sinnlos, dass jede Instanz ihren eigenen Zähler führt.

Sechs HTTP-Security-Header sind definiert: CSP, nosniff, Framing-Verbot, Referrer-Policy, HSTS und eine eingeschränkte Permissions-Policy. Nutzereingaben (Bewertungen, Retourengründe, Bestellnotizen, Profiltexte, Kontaktformular) werden bereinigt. Das Rate Limiting läuft über einen zentralen, datenbankgestützten Limiter. Es gibt drei Rollen — ADMIN, SALES, USER — und jede geschützte Server Action prüft zusätzlich die Session. Die Mock-Zahlung wird über eine ausschließlich serverseitig lesbare Variable gesteuert und in der Produktion ohne ausdrückliche Freigabe abgelehnt. Retourenfreigaben und Bestandsbewegungen werden ins Audit-Log geschrieben.

Die automatische Memoization des React Compilers ist aktiv; Diagrammkomponenten werden per Dynamic Import aus dem Hauptbundle herausgelöst, und die Startseite streamt hinter Suspense-Grenzen. Der Server-Action-Cache wird tagbasiert invalidiert, sodass eine Produktaktualisierung den betreffenden Tag statt der ganzen Seite auffrischt. Bilder werden als AVIF und WebP ausgeliefert, die Bundle-Analyse liegt als fertiger Befehl im Repository. Zehn Playwright-Smoke-Tests decken Produktlebenszyklus, Gutschein- und Retourenabläufe ab. Lighthouse mobil (eigene Messung, Median aus 4 warmen Durchläufen): 59/100 — September 2026. Der Wert ist niedrig, und die Messung zeigt den Grund: Es kostet die Zeit bis zum ersten Byte, nicht blockierendes Skript — ein FCP-Median von 6,1 Sekunden bei einer Gesamtblockierzeit von 36 ms. Die Shopseite wird bei jeder Anfrage serverseitig erzeugt; der eigentliche Gewinn liegt darin, die Produktliste aus dem Rendering pro Anfrage in revalidierte statische Ausgabe zu überführen.

Schema

31 Prisma-Modelle · 32 Migrationen

TypeScript-Quelldateien

390

E2E-Testdateien

10 (Playwright)

Aktive Entwicklung

2026-05 → 2026-08 · 41 Commits

Zahlungsgarantie

Ein wiederholter Callback kann keine zweite Bestellbestätigung erzeugen; die Bestandsminderung teilt sich eine Transaktion mit dem Bestelldatensatz

Die Zahlungs- und Bestandsseite würde ich heute genauso bauen, aber die Reihenfolge ändern: Das Idempotenz-Constraint würde ich zuerst schreiben. Hier habe ich mit einer "bereits bezahlt?"-Prüfung begonnen und die Race Condition erst danach geschlossen — genau das, was beim Problem der doppelten Bestätigung in Görev Kahramanı passiert ist, wo ich die Garantie ebenfalls nachträglich ergänzt habe. Zweitens würde ich die Bestands- und Zahlungsregeln früher in die Datenbank verlagern, um nicht den Wartungsaufwand zu wiederholen, den ich bei Bergaz Analiz dafür zahle, dass die Periodensperre in der Anwendungsschicht geblieben ist. Drittens bildet eine Performance-Messung bei gemockter Zahlung die reale Last nicht ab; vor dem Einsatz der produktiven Zugangsdaten und ohne eine mit Datum versehene Messung hat es keinen Sinn, einen Score zu veröffentlichen.