Backend-Architektur erklärt: So funktioniert eine Production App

Kurz erklärt

• Das backend ist wie ein gebäude mit türsteher, der jeden checkt
• Programme können mehrfach laufen (instanzen), um viele nutzer gleichzeitig zu bedienen
• Der cache ist ein zwischenspeicher für häufige anfragen, damit die datenbank nicht überlastet wird
• Die queue ist wie ein schlauch mit aufgaben - services nehmen sich welche, wenn sie zeit haben
• Admin und user haben komplett getrennte zugänge
• Kubernetes macht die skalierung automatisch

Letztens wurde ich gefragt: "Wie sieht eigentlich das backend deiner app aus?" Gute frage. Ich hab mir gedacht, ich zeig's euch mal - nicht mit fancy diagrammen, sondern so wie ich es mir selbst vorstelle.

Das ist übrigens eine echte production app für einen kunden mit mehreren tausend nutzern. Also keine spielerei, sondern das, was gerade live läuft.

3:00

Die App und der Türsteher

Stell dir das ganze wie ein gebäude vor. Die app ist das, was die nutzer sehen und anfassen können - quasi der eingang. Aber bevor irgendwer reinkommt, steht da der türsteher.

Der türsteher ist eine software, die jeden checkt: "Wer bist du? Was willst du? Darfst du das?" Erst wenn alles passt, leitet er die anfrage ans interne netzwerk weiter. Niemand kommt am türsteher vorbei. Das ist wichtig für die sicherheit.

Das interne Netzwerk - Server und Programme

Hinter dem türsteher liegt das interne netzwerk. Stell dir das wie mehrere kreise vor - das sind die server. In jedem server laufen verschiedene programme, die ich mir wie rechtecke vorstelle.

Das spannende: Die wichtigen programme gibt's mehrfach. Der user service zum beispiel - der kümmert sich um nutzeranmeldungen und profile. Den hab ich nicht nur einmal, sondern mehrmals laufen. Auf verschiedenen servern sogar.

Warum? Ganz einfach: Wenn sich gerade 1000 nutzer gleichzeitig anmelden wollen, würde ein einzelner service absaufen. Mit mehreren instanzen verteilt sich die last. Ist wie an der supermarktkasse - eine kasse bei rush hour wäre wahnsinn, fünf kassen machen's entspannt.

Die Datenbank - wo alles landet

All diese programme müssen irgendwo ihre daten speichern. Nutzerprofile, einstellungen, artikel, alles. Das macht die datenbank.

Die programme kommunizieren isoliert mit der datenbank. Jeder holt sich was er braucht, speichert was er muss, aber sie quatschen nicht durcheinander. Das macht das system stabil. Wenn ein programm abstürzt, läuft der rest weiter.

Der Cache - der Turbo-Zwischenspeicher

Zwischen dem türsteher und allem anderen sitzt noch der cache. Stell dir den wie einen kleinen zwischenspeicher vor.

Beispiel: Ein blogartikel wird 500 mal am tag aufgerufen. Ohne cache würde der türsteher 500 mal zur datenbank rennen, den artikel holen und zurückgeben. Mit cache? Einmal holen, im cache speichern, 499 mal aus dem cache servieren. Ist wie wenn du dir die milch neben den kaffee stellst statt jedes mal zum kühlschrank zu laufen.

Der cache ist schneller als die datenbank. Viel schneller. Millisekunden vs sekunden. Bei tausenden anfragen pro minute macht das den unterschied zwischen "läuft smooth" und "server brennt".

Das Admin-Dashboard - die Chefetage

Jetzt wird's interessant. Es gibt noch eine zweite tür ins gebäude - das admin-dashboard. Das ist eine web-applikation, über die ich alles kontrollieren kann. Neue artikel schreiben, nutzer verwalten, statistiken checken.

Diese tür hat ihren eigenen sicherheitstypen. Der ist strenger, aber darf auch mehr. Während der normale türsteher nur lesen und begrenzt ändern lässt, kann der admin-türsteher alles. Daten löschen, server neustarten, komplette kontrolle.

Wichtig: Der admin-bereich cached nichts. Ich will immer aktuelle daten sehen. Wenn ein nutzer sich gerade registriert hat, will ich das sofort sehen, nicht erst in 5 minuten wenn der cache updated. Die wartezeit ist mir hier egal - ich bin ja nicht der endnutzer der ungeduldig wartet.

Die Queue - der Aufgaben-Schlauch

Fast hätte ich's vergessen - die queue. Die stelle ich mir wie einen schlauch vor, in dem einzelne nachrichten drin sind. Wie kugeln in einer röhre.

Ein service generiert eine aufgabe: "Schicke push notification an 5000 nutzer". Die aufgabe kommt in die queue. Irgendein service der gerade zeit hat, nimmt sich die aufgabe raus, bearbeitet sie, markiert sie als fertig und holt sich die nächste.

Was kommt alles in die queue?

• Push notifications (kann dauern bei tausenden nutzern)
• Übersetzungen (api calls zu deepl)
• Bildbearbeitung (thumbnails generieren)
• Email-versand
• Reports erstellen

Der vorteil: Der hauptserver wird nicht blockiert. Die app bleibt responsive während im hintergrund die schweren aufgaben abgearbeitet werden.

Externe APIs - die Spezialisten

Wir machen nicht alles selbst. Für spezialaufgaben holen wir uns externe hilfe:

Firebase für push notifications - die wissen wie man nachrichten an ios und android schickt DeepL oder ChatGPT für übersetzungen und ki-features Payment provider für zahlungen (will ich nicht selbst bauen, zu riskant)

Die verbindung ist bidirektional. Wir schicken daten hin, bekommen ergebnisse zurück. Die einzelnen services managen diese verbindungen. Wenn deepl mal down ist, läuft die app trotzdem weiter, nur übersetzungen funktionieren halt nicht.

Eine moderne Weiterentwicklung in der Backend-Architektur ist Server-Driven UI, bei der das Backend nicht nur Daten, sondern auch UI-Komponenten steuert.

Kubernetes - der Automatisierer

Das ganze läuft in einem Kubernetes cluster. Kubernetes ist wie ein manager der alles automatisch regelt.

Ich sage kubernetes: "Der user service soll bei 70% auslastung eine neue instanz starten". Kubernetes checkt ständig die auslastung. Steigt sie über 70%? Zack, neue instanz. Fällt sie wieder? Instanz wird runtergefahren.

Beispiel aus der praxis: Marketing macht eine kampagne, plötzlich kommen 10x mehr nutzer. Früher wäre der server abgestürzt. Heute skaliert kubernetes automatisch hoch. Von 2 auf 10 instanzen in minuten. Die kampagne ist vorbei? Skaliert wieder runter, spart kosten.

Ich muss nur die schwellenwerte setzen:

• Ab wann hochskalieren?
• Wie viele instanzen maximal?
• Wie lange warten vor runterskalieren?

Den rest macht kubernetes. Ich schlafe ruhig während meine app automatisch mit der last umgeht.

Der Unterschied zu kleinen Apps

Bei einer kleinen app würde das alles übertrieben sein. Da reicht ein server wo alles drauf läuft. Frontend, backend, datenbank, fertig. Es ist oft besser, ohne perfekte Architektur zu starten und später zu skalieren.

Aber ab einer gewissen größe brauchst du diese aufteilung. Nicht weil es cool ist, sondern weil es anders nicht funktioniert. Tausende gleichzeitige nutzer bringen einen einzelnen server zum kochen.

Die architektur die ich gezeigt habe ist für apps mit mehreren tausend aktiven nutzern. Darunter ist es overkill. Darüber wird's noch komplexer mit mehreren regionen, failover, disaster recovery.

Was bedeutet das konkret?

Diese architektur gibt mir:

• Stabilität: Ein service stirbt? Die anderen laufen weiter
• Skalierbarkeit: Von 10 auf 10.000 nutzer ohne umbauen
• Flexibilität: Neue features als neuer service, ohne alles anzufassen
• Performance: Cache und mehrere instanzen = schnelle antworten
• Sicherheit: Mehrere sicherheitsebenen, getrennte bereiche

Der preis dafür ist komplexität. Mehr teile die kaputt gehen können. Mehr zu überwachen. Mehr zu verstehen. Aber für eine production app mit echten nutzern führt kein weg daran vorbei.

Das ist die realität hinter einer modernen app. Kein einzelner server der alles macht, sondern ein system aus vielen teilen die zusammenarbeiten. Wie ein orchester - jeder spielt sein instrument, zusammen entsteht die musik.

Wenn du Unterstützung bei der Umsetzung einer solchen Architektur brauchst, biete ich professionelle Backend-Entwicklung an.

Häufig gestellte Fragen