--- title: "Backend-Architektur erklärt: So funktioniert eine Production App" description: "Ein visueller Einblick in die Backend-Architektur einer echten Production App mit tausenden Nutzern. Cache, Queue, Kubernetes und mehr einfach erklärt." canonical_url: "https://robocitrus.com/blog/so-funktioniert-das-backend-meiner-production-app" last_updated: "2026-07-19T00:14:35.042Z" --- ## 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. ## 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](/blog/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](https://kubernetes.io/) 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](/blog/warum-erste-app-ohne-perfekte-architektur-besser-als-keine-app) 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](/leistungen/backend-entwicklung) an. ## Häufig gestellte Fragen Für eine kleine app mit unter 100 nutzern brauchst du das nicht. Ein einzelner server mit allem drauf reicht völlig aus. Ab etwa 1.000 aktiven nutzern oder wenn du schnelles wachstum erwartest, macht die aufteilung in services, cache und queue sinn. Bei mehreren tausend nutzern ist es quasi pflicht, wenn du eine stabile app haben willst. Das kommt stark auf die nutzerzahl an. Für eine app mit 2.000-5.000 aktiven nutzern kannst du mit 200-500€ monatlich rechnen (server, datenbank, cache, kubernetes). Bei 10.000+ nutzern eher 500-1.500€. Die kosten skalieren nicht linear - ab bestimmten schwellenwerten gibt's mengenrabatte bei den cloud-anbietern. Mehr Details zu den [laufenden Kosten einer App](/blog/laufende-app-kosten) findest du in unserem ausführlichen Artikel. Technisch ja, aber es macht oft keinen sinn. Kubernetes bringt overhead - du musst es lernen, konfigurieren, überwachen. Für ein hobby-projekt oder einen mvp ist das overkill. Nutze kubernetes erst, wenn du wirklich mehrere services und automatische skalierung brauchst. Für den start reichen managed services wie [Railway](https://railway.app/), [Render](https://render.com/) oder [Fly.io](https://fly.io/) völlig aus. Der wechsel ist nicht trivial, aber machbar. Das schwierigste ist, den monolithen in einzelne services aufzuteilen. Du musst überlegen: welche teile können unabhängig laufen? Wo sind die grenzen? Cache und queue lassen sich relativ einfach hinzufügen. Kubernetes ist am anfang steil, aber mit tutorials und managed kubernetes ([GKE](https://cloud.google.com/kubernetes-engine), [EKS](https://aws.amazon.com/eks/), [AKS](https://azure.microsoft.com/en-us/products/kubernetes-service)) kommst du schnell rein. Plan 2-4 wochen für den umbau ein. Geschwindigkeit und kostenersparnis. Ohne cache hämmerst du bei jedem request auf die datenbank ein. Das ist langsam (200-500ms) und teuer (datenbank-ressourcen kosten geld). Mit cache sind häufige anfragen in 5-20ms beantwortet. Bei 1.000 requests pro minute sparst du mehrere hundert sekunden datenbankzeit - das ist der unterschied zwischen smooth und laggy. Nein, nur die kritischen. Der user service und der haupt-api service sollten mehrere instanzen haben, weil da die meiste last ankommt. Kleinere services wie ein cronjob für backups oder ein reporting-service können auch einzeln laufen. Schaue, wo die bottlenecks sind, und skaliere gezielt. Du kannst auch mit einer instanz pro service starten und bei bedarf hochskalieren. Die app läuft weiter, aber das feature funktioniert nicht. Wenn deepl down ist, funktionieren übersetzungen halt nicht - der rest der app ist aber noch da. Deshalb ist es wichtig, externe abhängigkeiten zu isolieren. Nutze timeouts, fallbacks und zeig dem nutzer eine sinnvolle fehlermeldung. Bei kritischen services wie payment kannst du auch mehrere anbieter parallel nutzen (failover).