01 · Problem
Drei Produkte, die sonst für sich stehen, kamen in eine App: Ticketverkauf, bezahlte Inhalte und ein Marktplatz mit mehreren Verkäufern. Alle drei berühren Geld, und jedes hat eine eigene Regel, wann Geld als bewegt gilt — ein Ticket wird vorab bezahlt und beim Event eingelöst, Inhalte werden einmal freigeschaltet und bleiben es, eine Bestellung wird erst abgerechnet, wenn die Ware ankommt. Unter einem Konto müssen sich alle drei trotzdem wie eine einzige Historie lesen.
02 · Ansatz
Entscheidend sind hier nicht die Anzahl der Funktionen, sondern die Grenzen, die das Backend halten muss. Verkäuferbestand und Ticketkontingente sind endliche Ressourcen, um die zwei Käufer in derselben Sekunde konkurrieren können, und dieser Konflikt muss in der Datenbank entschieden werden — die Anwendungsschicht läuft womöglich in mehreren Prozessen gleichzeitig, und eine Prüfung dort sieht ihre Nachbarn nicht. Geld verlangt außerdem eine nachvollziehbare Historie: Die Frage, die später immer kommt, ist nicht, welchen Status etwas jetzt hat, sondern wann er sich änderte und auf welcher Grundlage.