Wofür das Backend tatsächlich verantwortlich ist
Nutzer sehen das Backend nie, deshalb wird es als Erstes unzureichend spezifiziert und geht als Erstes kaputt. Seine Aufgabe ist es, die Wahrheit zu halten: Geschäftsregeln durchsetzen, garantieren, dass gleichzeitige Aktionen sich nicht gegenseitig beschädigen, eine genaue Historie führen und reaktionsschnell bleiben, wenn das Volumen wächst.
Die meisten Produktionsvorfälle, zu denen wir gerufen werden, gehen auf dieselben wenigen Ursachen zurück: Autorisierung, die nur in der Oberfläche umgesetzt ist, keine Transaktionsgrenzen um mehrstufige Vorgänge, langsame Abfragen, die mit tausend Zeilen noch funktionierten, und keine Aufzeichnung, wer was geändert hat.
Was wir bauen
- Design, Versionierung und Dokumentation von REST- und GraphQL-APIs
- Relationale und dokumentenbasierte Datenmodellierung
- Authentifizierung, Autorisierung, Rollen und Berechtigungen
- Hintergrundjobs, Warteschlangen und zeitgesteuerte Verarbeitung
- Caching-Strategie mit Redis oder Vergleichbarem
- Suchfunktionen mit Elasticsearch oder Ähnlichem
- Verarbeitung von Zahlungen, Rechnungen und Finanztransaktionen
- Drittanbieter-Integrationen mit Wiederholungslogik und Monitoring
- Audit-Logging und Datenhistorie
- Performance-Analyse, Abfrageoptimierung und Lasttests
Datenmodellierung ist die Entscheidung, die man nicht rückgängig macht
Frameworks lassen sich austauschen und Oberflächen neu gestalten. Ein Datenmodell, das von Anfang an falsch war, setzt sich in jede Abfrage, jeden Bericht und jede Integration fort, und eine spätere Korrektur bedeutet eine Migration, die alles berührt.
Deshalb investieren wir Zeit, bevor wir Code schreiben: Was sind die realen Entitäten Ihres Geschäfts und nicht das, was der erste Bildschirm nahelegte, wo liegen die tatsächlichen Beziehungen, was muss eindeutig sein, welche Historie muss erhalten bleiben und welche Werte werden berechnet statt gespeichert. Das richtig zu machen ist die wirkungsvollste Stunde im ganzen Projekt.
Korrekt bei Nebenläufigkeit, schnell unter Last
Systeme, die im Test perfekt funktionieren, scheitern in der Produktion, weil es dort Nebenläufigkeit gibt. Zwei Personen senden dasselbe Formular ab, ein Zahlungs-Webhook kommt zweimal an, ein zeitgesteuerter Job überschneidet sich mit sich selbst, und plötzlich gibt es zwei Bestellungen, wo eine sein sollte.
Wir behandeln das bewusst: Transaktionen mit korrekten Grenzen, Idempotenzschlüssel für alles, was wiederholt werden kann, Constraints auf Datenbankebene statt Hoffnung auf Anwendungsebene und Sperren, wo sie wirklich nötig sind. Für die Performance indexieren wir nach den tatsächlichen Abfragemustern, beseitigen Abfragen, die sich mit der Zeilenzahl vervielfachen, cachen, was teuer und stabil ist, und verlagern langsame Arbeit in Warteschlangen, damit keine Anfrage auf den Versand einer E-Mail wartet.
Sicherheit und Nachvollziehbarkeit
Autorisierung gehört auf den Server, geprüft an jedem Endpunkt, jedes Mal. Eine Oberfläche, die eine Schaltfläche ausblendet, ist eine Usability-Funktion, keine Sicherheitsmaßnahme, und das ist der häufigste schwerwiegende Fehler, den wir in bestehenden Systemen finden.
Darüber hinaus: parametrisierte Abfragen, Validierung an der Schnittstelle, Secrets in einem Manager statt im Code, Verschlüsselung sensibler Felder im Ruhezustand, Rate Limiting und ein Audit-Trail, der festhält, wer was wann geändert hat. Der Audit-Trail wirkt optional bis zum ersten Streitfall, und dann ist er das Wertvollste in der Datenbank.