{ "id": 36979, "slug": "2020-05-11_skalierbares-anwendungsdesign-ohne-magie", "url": "https://agents.willem.com/de/posts/2020-05-11_skalierbares-anwendungsdesign-ohne-magie/", "source_url": "https://willem.com/de/2020-05-11_skalierbares-anwendungsdesign-ohne-magie/", "language": "de", "date": "2020-05-11", "published": "2020-05-11T00:00:00+02:00", "created": "2025-06-26T22:09:59.814000+02:00", "updated": "2026-10-20T09:19:34.116000+02:00", "title": "Skalierbares Anwendungsdesign ohne Magie", "subtitle": "Die Rechenleistung der Clients nutzen, für hohe Leistung bei vielen Nutzern", "summary": "Für die Online-Bestell-App, die ich gerade baue, brauchte ich eine skalierbare Backend-Infrastruktur, die viele gleichzeitige Nutzer verkraftet. Skalierbarkeit gilt als schwieriges Problem. Oft wird sie dargestellt, als wäre sie Magie, die nur millionenschwere Firmen mit geheimen Werkzeugen beherrschen. Aber so etwas wie Magie gibt es nicht. Oder etwa doch?", "topics": [ "cloud", "data", "design", "howto", "iOS", "lemmid-store", "programming", "server", "smartphone", "web", "webdesign" ], "author": { "name": "Willem L. Middelkoop", "url": "https://willem.com" }, "provenance": { "kind": "model", "method": "Gemini translation (2025), reviewed and corrected by Claude Sonnet (20 Oct 2026) against a glossary and hunspell", "date": "2026-10-20", "reviewed_by_native_reader": false, "language": "de", "source_language": "en" }, "translations": [ { "language": "en", "title": "Scalable application design without magic", "url": "https://agents.willem.com/en/posts/2020-05-11_scalable-application-design-without-magic/", "source_url": "https://willem.com/en/2020-05-11_scalable-application-design-without-magic/" }, { "language": "nl", "title": "Schaalbaar applicatieontwerp zonder magie", "url": "https://agents.willem.com/nl/posts/2020-05-11_schaalbaar-applicatieontwerp-zonder-magie/", "source_url": "https://willem.com/nl/2020-05-11_schaalbaar-applicatieontwerp-zonder-magie/" }, { "language": "es", "title": "Diseño de aplicaciones escalables sin magia", "url": "https://agents.willem.com/es/posts/2020-05-11_diseno-de-aplicaciones-escalables-sin-magia/", "source_url": "https://willem.com/es/2020-05-11_diseno-de-aplicaciones-escalables-sin-magia/" }, { "language": "fr", "title": "Concevoir une application scalable sans magie", "url": "https://agents.willem.com/fr/posts/2020-05-11_concevoir-une-application-scalable-sans-magie/", "source_url": "https://willem.com/fr/2020-05-11_concevoir-une-application-scalable-sans-magie/" }, { "language": "it", "title": "Progettare applicazioni scalabili senza magia", "url": "https://agents.willem.com/it/posts/2020-05-11_progettare-applicazioni-scalabili-senza-magia/", "source_url": "https://willem.com/it/2020-05-11_progettare-applicazioni-scalabili-senza-magia/" }, { "language": "pt", "title": "Design de aplicações escaláveis sem magia", "url": "https://agents.willem.com/pt/posts/2020-05-11_design-de-aplicacoes-escalaveis-sem-magia/", "source_url": "https://willem.com/pt/2020-05-11_design-de-aplicacoes-escalaveis-sem-magia/" }, { "language": "pap", "title": "Desèño di aplikashon eskalabel sin magia", "url": "https://agents.willem.com/pap/posts/2020-05-11_deseno-di-aplikashon-eskalabel-sin-magia/", "source_url": "https://willem.com/pap/2020-05-11_deseno-di-aplikashon-eskalabel-sin-magia/" }, { "language": "fy", "title": "Skaalbere applikaasje-ûntwerp sûnder magy", "url": "https://agents.willem.com/fy/posts/2020-05-11_skaalbere-applikaasje-untwerp-sunder-magy/", "source_url": "https://willem.com/fy/2020-05-11_skaalbere-applikaasje-untwerp-sunder-magy/" } ], "image": "https://willem.com/global/images/b11642014936.webp", "image_width": 2560, "images": [ { "url": "https://willem.com/global/images/02bda6e71f78.webp", "description": "Ein Nutzer arbeitet mit einem Server", "manager_file": "148-bf2d6faf6057f115dc72e82d984e71359f16b48d8c42b4b41c2ee918cf46b556_ContentAsPost_36979_images-1.png" }, { "url": "https://willem.com/global/images/0983daa5d3fa.webp", "description": "Server unter hoher Last, der mehrere gleichzeitige Nutzer bedient", "manager_file": "148-bf2d6faf6057f115dc72e82d984e71359f16b48d8c42b4b41c2ee918cf46b556_ContentAsPost_36979_images-2.png" }, { "url": "https://willem.com/global/images/e4d580ef3ee0.webp", "description": "Smartphones (und Tablets, PCs) sind im Lauf der Jahre immer leistungsfähiger geworden (Bild: Apple)", "manager_file": "148-bf2d6faf6057f115dc72e82d984e71359f16b48d8c42b4b41c2ee918cf46b556_ContentAsPost_36979_images-3.jpg" }, { "url": "https://willem.com/global/images/3b24ef5be7d6.webp", "description": "Das Gerät des Nutzers einspannen: Sein Telefon übernimmt den Großteil der Arbeit, die ursprünglich der Server erledigt hat", "manager_file": "148-bf2d6faf6057f115dc72e82d984e71359f16b48d8c42b4b41c2ee918cf46b556_ContentAsPost_36979_images-4.png" }, { "url": "https://willem.com/global/images/d08b396a761f.webp", "description": "Essen online bestellen", "manager_file": "148-bf2d6faf6057f115dc72e82d984e71359f16b48d8c42b4b41c2ee918cf46b556_ContentAsPost_36979_images-5.jpg" }, { "url": "https://willem.com/global/images/1d2831da7a52.webp", "description": "Die restliche Serverlast aufteilen: Produkte ausliefern und Bestellungen verarbeiten", "manager_file": "148-bf2d6faf6057f115dc72e82d984e71359f16b48d8c42b4b41c2ee918cf46b556_ContentAsPost_36979_images-6.png" }, { "url": "https://willem.com/global/images/4c106f30570a.webp", "description": "Viel Traffic bewältigen durch verteiltes Rechnen", "manager_file": "148-bf2d6faf6057f115dc72e82d984e71359f16b48d8c42b4b41c2ee918cf46b556_ContentAsPost_36979_images-7.png" } ], "text": "Was ist Skalierbarkeit?\nWenn du eine App baust, fängst du wahrscheinlich ganz klein an. Nur ein paar Nutzer (oder nur du, der Entwickler) arbeiten mit der App. Alles ist bestens: Die App läuft gut und schnell, und es gibt keine Probleme. (Genieße dieses Gefühl!)\nIn diesem frühen, kleinen Szenario kommt der einzelne Server, auf dem die App läuft, mit dem Nutzer gut zurecht. Jedes Mal, wenn der Nutzer etwas antippt oder klickt, erledigt der Server ein bisschen Arbeit. Wenn du gut programmierst, lässt sich diese Arbeit in effiziente Häppchen packen. Das ist ein typisches Beispiel für eine monolithische_Software-Architektur (https://willem.com/en/2020-03-03_monolithic-vs-microservices-software-architecture/).\nAuch wenn dein Projekt oder deine App eher klein ist, kann irgendwann ein Schwung neuer Nutzer kommen. Wenn dein System hohe Lasten nicht tragen kann, geht es sehr wahrscheinlich schief.\nBei einem_monolithischen_App-Design (https://willem.com/en/2020-03-03_monolithic-vs-microservices-software-architecture/) sprechen alle Nutzer mit demselben Server. Alles, was sie tun (Tippen, Klicken, Eingaben), verarbeitet dieser Server. Steigt die Last, muss er viel härter arbeiten. Irgendwann merkst du, dass alles langsamer wird, weil der Server mit der Arbeit nicht mehr hinterherkommt. Das heißt, deine App skaliert nicht gut. Anders gesagt: Du hast ein Problem.\nAusfall im entscheidenden Moment\nSchlechte Skalierung ist ein großes Problem, das niemand unterschätzen sollte. Die meisten Apps (und ihre Geschäftsmodelle) leben von großen Mengen bei geringem Ertrag pro Nutzer. Soll deine App ein (finanzieller) Erfolg werden, muss sie auch bei plötzlich steigendem Traffic gut laufen. Stürzt deine App ab, wenn sie plötzlich die Aufmerksamkeit der Massen bekommt, verpasst du eine Chance auf (organisches) Wachstum, die vielleicht nie wiederkommt.\nSkalierbarkeit einzuplanen ist ein bisschen wie Anschnallen in deiner selbst gebauten Rakete mit experimentellen Triebwerken. Du weißt nie genau, wann sie zündet, aber wenn es so weit ist, solltest du fest sitzen (und den Flug genießen!).\nGängige Wege zu mehr Skalierbarkeit\nZum Bau skalierbarer Apps ist schon viel geschrieben worden. Gängige Wege sind:\n- Mehr Serverkapazität: mehr Arbeitsspeicher, CPU-Leistung, Speicherplatz. Das funktioniert, bringt dich aber nur \"bis zu einem gewissen Punkt\".\n- Mehr Server: Statt eines einzelnen Servers als Flaschenhals kannst du weitere Server einsetzen, die sich die Arbeit teilen. Das ist leichter gesagt als getan, denn du brauchst Load Balancing und gemeinsame Daten, und das kann knifflig sein (zum Beispiel: Wenn du einen Bestellzähler hast und zwei Server zählen, wer bestimmt dann die nächste Nummer?).\n- Den Programmcode optimieren: Nimm die richtigen Werkzeuge! Wähle eine leistungsorientierte Programmiersprache und passende Serversoftware. Schau dir funktionale Programmierung an, damit dein Code asynchron auf mehreren Kernen laufen kann. Mach ihn zustandslos. Miss die Leistung. Optimiere. Jede Millisekunde, die du bei einer einzelnen Anfrage gewinnst, summiert sich schnell, wenn viel los ist.\n- Die Datenbank nutzen und vom Anwendungsserver trennen: Wenn du eine Datenbank einsetzt, hol alles aus ihr heraus! Nutze Query-Caching, Indizes und Suchfunktionen. Die meisten Datenbanken bieten erprobte Clustering-Optionen. Erfinde das Rad nicht neu: Andere haben es längst perfektioniert.\nAm besten ziehst du alle diese Möglichkeiten in Betracht. Auch wenn du nicht sofort weitere Server hinzufügst, solltest du deinen Code so schreiben, dass es später möglich ist. Benchmarks und Optimierung gehören fest zu deiner Arbeit und sind kein nachträglicher Einfall.\nDie Rechenleistung der Clients nutzen\nWenn du alle gängigen Wege durchdacht hast, gibt es noch \"eine Sache\".\nDaran denken nur wenige Entwickler: Das Skalierungsproblem enthält die Lösung! Bei 1000 Nutzern hast du 1000 Computer mit leistungsstarken CPUs und viel Speicher. Moderne Computer und Smartphones können immer mehr.\nDu musst nur einen Weg finden, die Rechenleistung des Clients anzuzapfen. Das klingt vielleicht gemein (die Rechenleistung des Nutzers zu benutzen), aber es verschafft ihm ein viel besseres, schnelleres Erlebnis. Das Beste daran: Seine Rechenleistung wird für sein tolles Erlebnis verwendet, und dein Skalierungsproblem löst sich ganz nebenbei als glücklicher Nebeneffekt.\nWenn du die Rechenleistung des Nutzers einsetzt, hat der Server weniger zu tun. Statt dass der Server jedes Mal ein bisschen arbeitet, wenn der Nutzer tippt oder klickt, erledigt das nun größtenteils das Gerät des Nutzers. Das ist effizienter, als über WLAN oder 4G mit einem Server zu sprechen (spart Akku und Zeit).\nDas erfordert ein wenig Umdenken, aber das Prinzip lässt sich auch auf Webanwendungen übertragen. Statt alles auf dem Server zu erledigen, kannst du viel Arbeit auf den Client verlagern. Suchen, Stöbern, Filtern, Navigieren und sogar das Befüllen eines Warenkorbs funktionieren mit clientseitigem JavaScript. Du - lieber Entwickler - musst Wege finden, das umzusetzen. Aber wenn es dir gelingt, hast du nahezu unbegrenzte Skalierbarkeit in der Hand.\nIn der Praxis: die Bestell-App für Essen\nFür die Bestell-App_für_Essen (https://willem.com/en/2020-05-01_designing-an-interface-for-a-food-ordering-page/) habe ich nach Wegen gesucht, die Rechenleistung der Clients für hohe Leistung zu nutzen. Die größte Herausforderung bei Liefer- und Abholbestellungen ist, dass sie zur Essenszeit ihren Höhepunkt erreichen. Viele Leute nutzen die App ungefähr gleichzeitig. Das ist ein Rezept für Skalierungsprobleme.\nWenn du an Essensbestellungen im Netz denkst, kannst du den ganzen Ablauf in kleinere Schritte zerlegen:\n- 1) Die Seite öffnen: App oder Seite laden\n- 2) Die Auswahl durchstöbern: Produkte auflisten, Beschreibungen, Preise, Fotos usw. ansehen\n- 3) Gezielt suchen: nach Kategorie, Produktname usw.\n- 4) Ein Produkt auswählen: zur Bestellung hinzufügen\n- 5) Ein Produkt anpassen: Sauce, Beilage, Topping usw. wählen\n- 6) Deine Daten eingeben: Name, Telefonnummer, Lieferdetails usw.\n- 7) Die Bestellung bezahlen: Zahlungsmethode wählen, Verbindung zu deiner Bank oder Kreditkarte\n- 8) Die App schließen\nDie meisten dieser Schritte lassen sich so programmieren, dass der Server nicht nötig ist. Nur Schritt 1 (Laden) und Schritt 7 (Bezahlen) brauchen Kontakt zur Backend-Infrastruktur. Wichtig: Die Schritte 2 bis 5 wiederholen sich oft, denn Nutzer legen meist mehrere Produkte in ihre Bestellung.\nTeilt man die restliche Arbeit nach Aufgaben auf, lässt sich die Software weiter optimieren. Der \"Produktserver\" ist darauf ausgelegt, statische Inhalte (Texte, Preise, Bilder) auszuliefern, mit denen der Client das Stöbern aufbaut. Diesen Servertyp kannst du stark optimieren, mit Caching, HTTP/2, Komprimierung usw.\nNur Nutzer, die ihre Bestellung abschließen, werden zum \"Bestellserver\" weitergeleitet, der die Zahlung abwickelt. Er verbindet sich mit dem Zahlungsanbieter. Ist eine Zahlung abgeschlossen, meldet sich der Zahlungsanbieter beim Bestellserver und teilt den Zahlungsstatus mit. Das willst du vollständig (serverseitig) selbst in der Hand haben, so wie ich es getan habe, als ich früher ein_Zahlungssystem_entworfen_habe (https://willem.com/en/2020-03-25_designing-and-implementing-a-micro-payment-system/). Die Restlast auf dem \"Bestellserver\" ist viel kleiner, weil nicht jeder bestellt und ein Großteil der Bestellverarbeitung im Hintergrund laufen kann.\nFür maximale Skalierbarkeit kannst du ganz einfach mehrere Server einsetzen (oder ein Content Delivery Network nutzen), die die statischen Inhalte ausliefern. Für die Bestell-App verwende ich pro Restaurant einen eigenen \"Produktserver\". Das sorgt für hohe Leistung und kurze Ladezeiten. Die Leute merken, dass es schnell ist, manche können nicht glauben, dass das Webtechnik ist. Es ist fast magisch.\nFazit\nEine skalierbare Anwendung zu entwerfen geht ohne Magie und ohne Millionenbudget. Du musst nur gründlich nachdenken und die Chancen nutzen, die zusammen mit den Herausforderungen auftauchen.\nDas Problem enthält die Lösung. Viele gleichzeitige Nutzer sind nicht nur ein Problem: Sie bringen ihre eigene Rechenleistung mit, und die ist die Lösung! Du musst sie nur nutzen.", "word_count": 1149, "markdown_url": "https://agents.willem.com/de/posts/2020-05-11_skalierbares-anwendungsdesign-ohne-magie/post.md" }