--- title: "Backend Architecture Explained: How a Production App Works" description: "A visual insight into the backend architecture of a real production app with thousands of users. Cache, Queue, Kubernetes and more explained simply." canonical_url: "https://robocitrus.com/en/blog/so-funktioniert-das-backend-meiner-production-app" last_updated: "2026-01-29T00:00:00.000Z" locale: en meta: "og:description": "A visual insight into the backend architecture of a real production app with thousands of users. Cache, Queue, Kubernetes and more explained simply." "og:image": "https://robocitrus.com/images/blog/so-funktioniert-das-backend-meiner-production-app.webp" "og:title": "Backend Architecture Explained: How a Production App Works" --- > Index of every page on this site: [llms.txt](https://robocitrus.com/llms.txt) ![Backend Architecture Explained: How a Production App Works](https://robocitrus.com/cdn-cgi/image/w=2048,q=75/images/blog/so-funktioniert-das-backend-meiner-production-app.webp) # **Backend Architecture Explained: How a Production App Works** [![Maximilian Flechtner](https://robocitrus.com/cdn-cgi/image/q=75/images/about-me-maximilian-image.webp)**Maximilian Flechtner**](https://robocitrus.com/en/about) Published:November 5, 2025 Updated:January 29, 2026 1 min read [**Backend**](https://robocitrus.com/en/blog/tags/backend) [**Architecture**](https://robocitrus.com/en/blog/tags/architecture) [**Production**](https://robocitrus.com/en/blog/tags/production) [**Kubernetes**](https://robocitrus.com/en/blog/tags/kubernetes) [**Scaling**](https://robocitrus.com/en/blog/tags/scaling) [**API**](https://robocitrus.com/en/blog/tags/api) ## The basics - The backend is like a building with a bouncer who checks everyone - Programs can exist multiple times (instances) to serve many users simultaneously - The cache is like an intermediate storage that quickly answers frequent questions without bothering the database - The queue is like a tube with tasks - services pull out tasks when they have time - Admin access and user access are completely separated with different security types - Kubernetes handles all the scaling automatically based on thresholds Recently someone asked me: "What does your app's backend actually look like?" Good question. I thought I'd show you - not with fancy diagrams, but how I visualize it myself. By the way, this is a real production app for a client with several thousand users. Not a toy project, but what's running live right now. ## The App and the Bouncer Think of the whole thing like a building. The app is what users see and can touch - basically the entrance. But before anyone comes in, there's the bouncer. The bouncer is software that checks everyone: "Who are you? What do you want? Are you allowed to do that?" Only when everything checks out does it forward the request to the internal network. Nobody gets past the bouncer. That's important for security. ## The Internal Network - Servers and Programs Behind the bouncer lies the internal network. Imagine this as several circles - those are the servers. In each server, different programs run, which I visualize as rectangles. The exciting part: The important programs exist multiple times. The user service for example - it handles user logins and profiles. I don't just have it running once, but multiple times. Even on different servers. Why? Simple: If 1000 users want to log in simultaneously, a single service would drown. With multiple instances, the load is distributed. It's like at the supermarket checkout - one checkout during rush hour would be insane, five checkouts make it relaxed. ## The Database - Where Everything Lands All these programs need to store their data somewhere. User profiles, settings, articles, everything. That's what the database does. The programs communicate with the database in isolation. Everyone gets what they need, stores what they must, but they don't talk through each other. This makes the system stable. If a program crashes, the rest keeps running. ## The Cache - The Turbo Intermediate Storage Between the bouncer and everything else sits the cache. Think of it as a small intermediate storage. Example: A blog article is called up 500 times a day. Without cache, the bouncer would run to the database 500 times, fetch the article and return it. With cache? Fetch it once, store it in cache, serve it from cache 499 times. It's like putting the milk next to your coffee instead of running to the fridge every time. The cache is faster than the database. Much faster. Milliseconds vs seconds. With thousands of requests per minute, this makes the difference between "runs smooth" and "server on fire". ## The Admin Dashboard - The Executive Floor Now it gets interesting. There's a second door into the building - the admin dashboard. This is a web application through which I can control everything. Write new articles, manage users, check statistics. This door has its own security type. It's stricter, but also allowed to do more. While the normal bouncer only allows reading and limited changes, the admin bouncer can do everything. Delete data, restart servers, complete control. Important: The admin area doesn't cache anything. I always want to see current data. If a user just registered, I want to see it immediately, not in 5 minutes when the cache updates. Wait time doesn't matter here - I'm not the end user who's waiting impatiently. ## The Queue - The Task Tube I almost forgot - the queue. I visualize this as a tube with individual messages inside. Like balls in a pipe. A service generates a task: "Send push notification to 5000 users". The task goes into the queue. Some service that currently has time picks out the task, processes it, marks it as done, and gets the next one. What goes into the queue? - Push notifications (can take time with thousands of users) - Translations (api calls to deepl) - Image processing (generating thumbnails) - Email sending - Report creation The advantage: The main server isn't blocked. The app stays responsive while heavy tasks are processed in the background. ## External APIs - The Specialists We don't do everything ourselves. For special tasks, we get external help: **[**Firebase**](https://firebase.google.com/)** for push notifications - they know how to send messages to ios and android **[**DeepL**](https://www.deepl.com/)** or **[**ChatGPT**](https://openai.com/chatgpt)** for translations and ai features **Payment provider** for payments (don't want to build that myself, too risky) The connection is bidirectional. We send data there, get results back. The individual services manage these connections. If deepl goes down, the app still runs, just translations don't work. A modern advancement in backend architecture is [**Server-Driven UI**](https://robocitrus.com/en/blog/server-driven-ui), where the backend controls not just data, but also UI components. ## Kubernetes - The Automator The whole thing runs in a [**Kubernetes**](https://kubernetes.io/) cluster. Kubernetes is like a manager that automatically handles everything. I tell kubernetes: "The user service should start a new instance at 70% load". Kubernetes constantly checks the load. Goes above 70%? Boom, new instance. Goes down again? Instance is shut down. Example from practice: Marketing launches a campaign, suddenly 10x more users come. In the past, the server would have crashed. Today kubernetes scales up automatically. From 2 to 10 instances in minutes. Campaign is over? Scales back down, saves costs. I only have to set the thresholds: - When to scale up? - How many instances maximum? - How long to wait before scaling down? Kubernetes does the rest. I sleep soundly while my app automatically handles the load. ## The Difference to Small Apps For a small app, all this would be overkill. A single server with everything on it is enough. Frontend, backend, database, done. It's often better to [**start without perfect architecture**](https://robocitrus.com/en/blog/warum-erste-app-ohne-perfekte-architektur-besser-als-keine-app) and scale later. But above a certain size, you need this separation. Not because it's cool, but because it doesn't work otherwise. Thousands of simultaneous users bring a single server to its knees. The architecture I've shown is for apps with several thousand active users. Below that it's overkill. Above that it gets even more complex with multiple regions, failover, disaster recovery. ## What Does This Mean Concretely? This architecture gives me: - **Stability**: A service dies? The others keep running - **Scalability**: From 10 to 10,000 users without rebuilding - **Flexibility**: New features as a new service, without touching everything - **Performance**: Cache and multiple instances = fast responses - **Security**: Multiple security layers, separated areas The price for this is complexity. More parts that can break. More to monitor. More to understand. But for a production app with real users, there's no way around it. This is the reality behind a modern app. Not a single server doing everything, but a system of many parts working together. Like an orchestra - everyone plays their instrument, together they create the music. If you need support implementing such an architecture, I offer [**professional backend development**](https://robocitrus.com/en/leistungen/backend-entwicklung). ## Frequently Asked Questions For a small app with under 100 users you don't need this. A single server with everything on it is perfectly sufficient. From about 1,000 active users or if you expect rapid growth, the separation into services, cache and queue makes sense. With several thousand users it's basically mandatory if you want a stable app. It depends heavily on the number of users. For an app with 2,000-5,000 active users you can expect 200-500€ monthly (server, database, cache, kubernetes). With 10,000+ users rather 500-1,500€. Costs don't scale linearly - above certain thresholds there are volume discounts from cloud providers. More details on [**running costs of an app**](https://robocitrus.com/en/blog/laufende-app-kosten) in our comprehensive article. Technically yes, but it often doesn't make sense. Kubernetes brings overhead - you have to learn it, configure it, monitor it. For a hobby project or an mvp that's overkill. Use kubernetes only when you really need multiple services and automatic scaling. For starters, managed services like [**Railway**](https://railway.app/), [**Render**](https://render.com/) or [**Fly.io**](https://fly.io/) are perfectly sufficient. The switch isn't trivial, but doable. The hardest part is splitting the monolith into individual services. You have to think: which parts can run independently? Where are the boundaries? Cache and queue are relatively easy to add. Kubernetes has a steep learning curve at first, but with tutorials and 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)) you'll get the hang of it quickly. Plan 2-4 weeks for the conversion. Speed and cost savings. Without cache you hammer the database with every request. That's slow (200-500ms) and expensive (database resources cost money). With cache, frequent requests are answered in 5-20ms. With 1,000 requests per minute you save several hundred seconds of database time - that's the difference between smooth and laggy. No, only the critical ones. The user service and the main api service should have multiple instances because that's where most of the load comes. Smaller services like a cronjob for backups or a reporting service can also run individually. Look at where the bottlenecks are and scale strategically. You can also start with one instance per service and scale up as needed. The app keeps running, but the feature doesn't work. If deepl is down, translations don't work - but the rest of the app is still there. That's why it's important to isolate external dependencies. Use timeouts, fallbacks and show the user a meaningful error message. For critical services like payment you can also use multiple providers in parallel (failover). [**Server-Driven UI: The Game-Changer That Could Transform App Updates Forever** Server-Driven UI enables instant app updates without App Store wait times. Learn how Google, Airbnb and you can use SDUI with Flutter, SwiftUI or React Native.](https://robocitrus.com/en/blog/server-driven-ui) [**Social Login in Apps: Why You Should Offer Apple, Google & Co.** 50% of users abandon registration forms. With social login (Apple, Google, Facebook), you drastically reduce drop-off rates and improve UX.](https://robocitrus.com/en/blog/social-login-app) ## **Let's Connect! 🚀** ### **Ready for your next project? **
** Let's get started!** ![Maximilian Flechtner - Gründer](https://robocitrus.com/cdn-cgi/image/w=3840,f=png,q=75/images/about-me-maximilian-image.webp) #### **Maximilian Flechtner ** [flechtner@robocitrus.com](mailto:flechtner@robocitrus.com) [ +49 0176 41766223](tel:+4917641766223) ### **Let's get started** Tell me about your vision – just drop me an email or use the contact form. Let's plan your digital success together! 💪 [Send me an email](mailto:flechtner@robocitrus.com) [Contact Form](https://robocitrus.com/en/kontakt) ```json {"@context":"https://schema.org","@graph":[{"@id":"https://robocitrus.com/en#website","@type":"WebSite","description":"App Entwickler & Full-Stack Experte aus Deutschland. Ich baue skalierbare Apps, Backends und komplette Startup-Systeme mit Flutter, Go und Kubernetes.","inLanguage":"en-US","name":"Maximilian Flechtner - App Entwickler","url":"https://robocitrus.com/en","publisher":{"@id":"https://robocitrus.com/#/schema/organization/1"},"translationOfWork":{"@id":"https://robocitrus.com/#website"}},{"@id":"https://robocitrus.com/en/blog/so-funktioniert-das-backend-meiner-production-app#webpage","@type":"WebPage","dateModified":"2026-01-29T00:00:00.000Z","datePublished":"2025-11-05","description":"A visual insight into the backend architecture of a real production app with thousands of users. Cache, Queue, Kubernetes and more explained simply.","name":"Backend Architecture Explained: How a Production App Works","url":"https://robocitrus.com/en/blog/so-funktioniert-das-backend-meiner-production-app","breadcrumb":{"@id":"https://robocitrus.com/en/blog/so-funktioniert-das-backend-meiner-production-app#breadcrumb"},"isPartOf":{"@id":"https://robocitrus.com/en#website"},"potentialAction":[{"@type":"ReadAction","target":["https://robocitrus.com/en/blog/so-funktioniert-das-backend-meiner-production-app"]}],"primaryImageOfPage":{"@id":"https://robocitrus.com/#logo"}},{"@id":"https://robocitrus.com/#identity","@type":"Organization","alternateName":"Robocitrus","description":"App Entwickler & Full-Stack Experte aus Deutschland. Spezialisiert auf skalierbare Apps, Backend-Systeme und komplette Startup-Lösungen mit Flutter, GoLang und Kubernetes. Von der Idee bis zum Launch - alles aus einer Hand.","email":"flechtner@robocitrus.com","name":"Maximilian Flechtner - App Entwicklung","telephone":"0176 41766223","url":"https://robocitrus.com","address":{"@type":"PostalAddress","streetAddress":"Leppiner Dorfstraße 60","addressLocality":"Arendsee","addressRegion":"Sachsen-Anhalt","postalCode":"39619","addressCountry":"DE"},"contactPoint":{"@type":"ContactPoint","telephone":"0176 41766223","email":"flechtner@robocitrus.com"},"logo":{"@id":"https://robocitrus.com/#logo"}},{"@id":"https://robocitrus.com/en/blog/so-funktioniert-das-backend-meiner-production-app#article","dateModified":"2026-01-29T00:00:00.000Z","datePublished":"2025-11-05","description":"A visual insight into the backend architecture of a real production app with thousands of users. Cache, Queue, Kubernetes and more explained simply.","headline":"Backend Architecture Explained: How a Production App Works","inLanguage":"en-US","thumbnailUrl":"https://robocitrus.com/images/blog/so-funktioniert-das-backend-meiner-production-app.webp","wordCount":200,"@type":["Article","BlogPosting"],"author":{"@id":"https://robocitrus.com/#/schema/person/1"},"image":{"@id":"https://robocitrus.com/#/schema/image/1"},"isPartOf":{"@id":"https://robocitrus.com/en/blog/so-funktioniert-das-backend-meiner-production-app#webpage"},"keywords":["Backend","Architecture","Production","Kubernetes","Scaling","API"],"mainEntityOfPage":{"@type":"WebPage","@id":"https://robocitrus.com/en/blog/so-funktioniert-das-backend-meiner-production-app"},"publisher":{"@id":"https://robocitrus.com/#/schema/organization/1"}},{"@id":"https://robocitrus.com/en/blog/so-funktioniert-das-backend-meiner-production-app#breadcrumb","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","name":"Blog","item":"https://robocitrus.com/blog","position":1},{"@type":"ListItem","name":"Backend Architecture Explained: How a Production App Works","position":2}]},{"@id":"https://robocitrus.com/#/schema/person/1","@type":"Person","name":"Maximilian Flechtner","url":"https://robocitrus.com/about","image":{"@id":"https://robocitrus.com/#/schema/image/2"}},{"@id":"https://robocitrus.com/#/schema/organization/1","@type":"Organization","name":"Maximilian Flechtner - App Entwicklung","url":"https://robocitrus.com/","logo":{"@type":"ImageObject","url":"https://robocitrus.com/images/large-logo.webp"}},{"@id":"https://robocitrus.com/#logo","@type":"ImageObject","caption":"Maximilian Flechtner - App Entwicklung","contentUrl":"https://robocitrus.com/images/large-logo.webp","inLanguage":"en-US","url":"https://robocitrus.com/images/large-logo.webp"},{"@id":"https://robocitrus.com/#/schema/image/1","@type":"ImageObject","contentUrl":"https://robocitrus.com/images/blog/so-funktioniert-das-backend-meiner-production-app.webp","inLanguage":"en-US","url":"https://robocitrus.com/images/blog/so-funktioniert-das-backend-meiner-production-app.webp"},{"@id":"https://robocitrus.com/#/schema/image/2","@type":"ImageObject","contentUrl":"https://robocitrus.com/images/about-me-maximilian-image.webp","inLanguage":"en-US","url":"https://robocitrus.com/images/about-me-maximilian-image.webp"}]} ``` ## Sitemap See the full [sitemap](https://robocitrus.com/sitemap.md) for all pages.