{"id":29008,"date":"2026-07-31T21:37:00","date_gmt":"2026-07-31T19:37:00","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=29008"},"modified":"2026-07-31T11:39:26","modified_gmt":"2026-07-31T09:39:26","slug":"frontend-anhand-eines-ultra-large-scale-systems-wie-uber","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/07\/31\/frontend-anhand-eines-ultra-large-scale-systems-wie-uber\/","title":{"rendered":"Frontend anhand eines Ultra-Large-Scale Systems wie Uber"},"content":{"rendered":"\n
\n

Diese Arbeit wurde im Rahmen der Vorlesungsveranstaltung \u201eUltra Large Scale Systems\u201c erstellt.<\/p>\n\n\n\n

Abstract<\/h3>\n\n\n\n

Ultra-Large-Scale Systems (ULSS) wie Uber stellen aufgrund ihrer hohen Nutzerzahlen, globalen Verteilung, gro\u00dfen Datenmengen und kontinuierlichen Weiterentwicklung besondere Anforderungen an die Frontend-Architektur. Diese Arbeit untersucht zentrale Architekturentscheidungen f\u00fcr das Frontend einer Uber-\u00e4hnlichen Anwendung. Dabei werden Component-based Architecture, Single-Page Applications, Rendering-Strategien, State Management, Backend-Integration sowie Monolith- und Micro-Frontend-Ans\u00e4tze betrachtet.<\/p>\n\n\n\n

Auf Basis dieser Analyse werden separate monolithische Frontends als geeigneter Ansatz f\u00fcr das betrachtete Szenario ausgew\u00e4hlt. Erg\u00e4nzend wird ein hybrider Rendering-Ansatz mit einer Kombination aus Client-Side Rendering, Server-Side Rendering, Static Site Generation und Edge Rendering sowie eine Trennung von Client State und Server State empfohlen. Durch eine API-Gateway- und Backend-for-Frontend-Schicht werden die Frontends von der Backend-Komplexit\u00e4t entkoppelt, w\u00e4hrend WebSockets die erforderliche Echtzeitkommunikation erm\u00f6glichen. Zus\u00e4tzlich unterst\u00fctzt ein zentrales Designsystem die Konsistenz sowie Wiederverwendbarkeit von UI-Komponenten und erm\u00f6glicht somit eine einheitliche User Experience (UX). Die Untersuchung zeigt, dass eine geeignete Frontend\u2011Architektur f\u00fcr ein ULSS durch eine gezielte Abstimmung zentraler Architekturentscheidungen auf beherrschbare Komplexit\u00e4t, einheitliches State\u2011Management und konsistente UX\u2011Flows entsteht.<\/p>\n\n
\n\n

1. Einleitung<\/h2>\n\n\n\n

In der heutigen Zeit werden Anwendungen wie soziale Medien, Streaming-Plattformen oder Online-Marktpl\u00e4tze von Millionen von Menschen genutzt [1]<\/span>. Bei diesen Anwendungen handelt es sich h\u00e4ufig um Ultra-Large-Scale Systems<\/em> (ULSS), also softwareintensive Systeme, die sich durch enorme Gr\u00f6\u00dfenordnungen hinsichtlich Hardware, Umfang des Quellcodes, Anzahl der Nutzer sowie des verarbeiteten Datenvolumens auszeichnen [2]<\/span>. Weitere Eigenschaften von ULSSs umfassen eine dezentrale Datenhaltung sowie dezentrale Entwicklungs-, Weiterentwicklungs- und Betriebskontrollprozesse [2]<\/span>. Zudem enthalten sie heterogene, inkonsistente und sich kontinuierlich ver\u00e4ndernde Elemente und entwickeln sich w\u00e4hrend des Betriebs stetig weiter [2]<\/span>.<\/p>\n\n\n\n

Ein Beispiel f\u00fcr ein System dieser Gr\u00f6\u00dfenordnung ist Uber<\/strong>[3]<\/span>, eine weit verbreitete Ride-Hailing-Plattform, die Fahrg\u00e4ste mit Fahrern verbindet [4]<\/span>. Die Plattform erm\u00f6glicht es Fahrg\u00e4sten, Fahrten zu buchen, w\u00e4hrend Fahrer Fahrten annehmen und verwalten k\u00f6nnen [3]<\/span>. Neben diesen funktionalen Anforderungen muss Uber zahlreiche nicht-funktionale Anforderungen erf\u00fcllen. Dazu geh\u00f6ren unter anderem geringe Latenz und hohe Performance, hohe Verf\u00fcgbarkeit, Skalierbarkeit, globale Verteilung, Echtzeitf\u00e4higkeit sowie eine responsive User Interface (UI) und Unterst\u00fctzung verschiedener Plattformen [4]<\/span>.<\/p>\n\n\n\n

Damit Nutzer Uber effizient und komfortabel verwenden k\u00f6nnen, muss insbesondere das Frontend eine benutzerfreundliche und reaktionsschnelle Nutzererfahrung gew\u00e4hrleisten [4]<\/span>. Die Bedeutung des Frontends in ULSSs ist besonders hoch, da es den direkten Interaktionspunkt zwischen dem Unternehmen und den Nutzern darstellt [5]<\/span>. Es beeinflusst unter anderem ma\u00dfgeblich die User Experience (UX), Suchmaschinenoptimierung (SEO), Performance sowie die Markenwahrnehmung [5]<\/span>.<\/p>\n\n\n\n

Daraus ergibt sich die Forschungsfrage, wie ein Frontend f\u00fcr ein ULSS wie Uber architektonisch gestaltet werden sollte.<\/p>\n\n\n\n

Da der Fokus dieser Arbeit auf der Frontend-Architektur liegt, wird prim\u00e4r ein Web-Frontend betrachtet. Mobile Anwendungen sowie infrastrukturelle und fachliche Aspekte wie Cloud-Infrastruktur, Security, Payment, Matching oder Pricing werden nicht behandelt. Diese Eingrenzung erm\u00f6glicht eine gezielte Untersuchung zentraler Frontend-Architekturthemen wie Rendering, State Management und Frontend-Architekturmodelle.<\/p>\n\n\n\n

Basis der Arbeit bilden die im Vorlesungsmodell \u201cUltra-Large-Scale System\u201d erarbeitete Architecture Inception Canvas [6]<\/span> sowie die dort erarbeiteten funktionalen und nicht funktionalen Anforderungen f\u00fcr ein ULSS im Uber-Kontext [7]<\/span>.<\/p>\n\n\n\n

Zur Beantwortung der vorher genannten Forschungsfrage werden zun\u00e4chst in Abschnitt 2<\/a> grundlegende Konzepte moderner Frontend-Architekturen, wie die Component-Based Architecture (CBA) und Single-Page Applications (SPA), sowie verschiedene Ans\u00e4tze f\u00fcr Rendering und State Management betrachtet und miteinander verglichen. Dar\u00fcber hinaus werden in Abschnitt 3<\/a> Technologien f\u00fcr einen m\u00f6glichen Frontend-Stack vorgestellt. Anschlie\u00dfend werden verschiedene Ans\u00e4tze zur Backend-Integration in Abschnitt 4<\/a> sowie verschiedene Frontend-Architekturmodelle in Abschnitt 5<\/a> analysiert und verglichen. Darauf aufbauend wird in Abschnitt 6<\/a> ein geeignetes Frontend-Architekturmodell f\u00fcr ein ULSS im Kontext von Uber ausgew\u00e4hlt und in Abschnitt 7<\/a> konzeptionell dargestellt. In Abschnitt 8<\/a> wird das Designsystem von Uber vorgestellt und als geeigneter Ansatz f\u00fcr die Gestaltung des Frontends des betrachteten ULSSs eingeordnet. Anschlie\u00dfend erfolgt in Abschnitt 9<\/a> die Diskussion der Ergebnisse und relevanten Themen. Den Abschluss bilden das Fazit in Abschnitt 10<\/a> sowie der Ausblick auf zuk\u00fcnftige Entwicklungen in Abschnitt 11<\/a>.<\/p>\n\n
\n\n

2. Grundlagen der Frontend Architektur<\/h2>\n\n\n\n

Um die Grundlage f\u00fcr die sp\u00e4teren Architekturentscheidungen zu schaffen, werden in diesem Abschnitt die grundlegenden Konzepte moderner Frontend-Architekturen erl\u00e4utert.<\/p>\n\n\n\n

2.1. Architekturkonzepte f\u00fcr moderne Frontend-Anwendungen<\/h3>\n\n\n\n

Moderne Frontend-Anwendungen basieren auf verschiedenen Architekturkonzepten, welche die Struktur eines Systems ma\u00dfgeblich beeinflussen. Im Folgenden werden die Architekturkonzepte Component-based Architecture<\/em> (CBA) und Single-Page Application<\/em> (SPA) erl\u00e4utert, da sie die Grundlage vieler moderner Webanwendungen und damit auch des betrachteten ULSSs darstellen.<\/p>\n\n\n\n

2.1.1. Component-based Architecture<\/h4>\n\n\n\n

In der Component-based Architecture<\/em> (CBA) besteht die Software aus wiederverwendbaren, klar abgegrenzten Komponenten. Dabei kapseln die Komponenten bestimmte Funktionalit\u00e4ten, Daten und Verhalten sowie klar definierte Schnittstellen. Dank dieser Konstellation wird die Wiederverwendbarkeit von Komponenten gef\u00f6rdert und die allgemeine Wartbarkeit, Skalierbarkeit sowie Flexibilit\u00e4t des Systems verbessert. Zudem wird dadurch auch die parallele Entwicklung im Team erleichtert [8]<\/span>.<\/p>\n\n\n\n

Allerdings ist zu beachten, dass mit steigender Anzahl an Komponenten die Komplexit\u00e4t der Verwaltung ihrer gegenseitigen Abh\u00e4ngigkeiten erheblich zunimmt. Zudem muss die passende Granularit\u00e4t der Komponenten bestimmt werden: W\u00e4hrend eine zu feine Granularit\u00e4t durch zus\u00e4tzliche Kommunikation und Verwaltungsaufwand zu Performance Overhead f\u00fchren kann, reduziert eine zu grobe Granularit\u00e4t die Wiederverwendbarkeit und Flexibilit\u00e4t der Komponenten [8]<\/span>.<\/p>\n\n\n\n

2.1.2. Single Page Application<\/h4>\n\n\n\n

Bei der Single Page Application<\/em> (SPA) wird in einer Webanwendung zun\u00e4chst nur ein einzelnes Web-Dokument geladen [9]<\/span>. Anschlie\u00dfend werden die ben\u00f6tigten Inhalte auf Basis von Nutzerinteraktionen dynamisch nachgeladen und aktualisiert, sodass auf ein vollst\u00e4ndiges Neuladen der Seite verzichtet werden kann [10]<\/span>.<\/p>\n\n\n\n

Auf diese Weise wird eine schnellere Interaktion nach dem initialen Laden der Seite erm\u00f6glicht und die Performance durch den Verzicht auf vollst\u00e4ndige Seiten-Neuladungen verbessert. Zudem k\u00f6nnen gezielte Datenabfragen die \u00dcbertragung unn\u00f6tiger Daten reduzieren und dadurch die Effizienz der Anwendung erh\u00f6hen. Daf\u00fcr verlangsamt der initiale Ladeprozess zun\u00e4chst den ersten Seitenaufbau. Auch kann der hohe Anteil an JavaScript bei dynamischen Inhalten m\u00f6glicherweise zu Schwierigkeiten bei der SEO f\u00fchren [10]<\/span>.<\/p>\n\n\n\n

Zusammenfassend l\u00e4sst sich feststellen, dass SPAs geeignet f\u00fcr interaktive Webanwendungen sind, die unter anderem Echtzeit- oder dynamische Daten beinhalten [10]<\/span>.<\/p>\n\n\n\n

2.2 Rendering<\/h3>\n\n\n\n

Das Rendering beschreibt den Prozess der Erzeugung und Darstellung der einer Webanwendung im Browser [11]<\/span>. Die Wahl der Rendering-Strategie beeinflusst dabei wesentliche Eigenschaften des Frontends, insbesondere die initiale Ladezeit, Performance, Interaktivit\u00e4t sowie SEO [12]<\/span>. Abh\u00e4ngig von den Anforderungen einer Anwendung k\u00f6nnen unterschiedliche Rendering-Methoden eingesetzt oder kombiniert werden. Folglich werden im Folgenden \u00fcbliche Rendering-Methoden vorgestellt.<\/p>\n\n\n\n

2.2.1. Server-Side Rendering<\/h4>\n\n\n\n

Ein klassischer Ansatz bildet das Server-Side Rendering<\/em> (SSR), bei dem das HTML-Dokument bei jeder Anfrage serverseitig erzeugt wird. Beim Aufruf einer Webseite wird eine Anfrage an den Server gesendet. Der Server verarbeitet diese Anfrage, l\u00e4dt die ben\u00f6tigten Daten und rendert daraus das HTML-Dokument. Anschlie\u00dfend wird die generierte Seite an den Browser \u00fcbertragen [12]<\/span>.<\/p>\n\n\n\n

SSR eignet sich besonders gut f\u00fcr Webseiten, bei denen eine schnelle initiale Auslieferung und eine gute SEO wichtig sind. Bei stark dynamischen Webanwendungen kann SSR jedoch aufgrund h\u00e4ufiger Serververarbeitung und erneuter Seitengenerierung an Grenzen sto\u00dfen [12]<\/span>.<\/p>\n\n\n\n

2.2.2. Client-Side Rendering<\/h4>\n\n\n\n

Durch die steigenden Anforderungen an die Interaktivit\u00e4t moderner Webanwendungen entstand das Client-Side Rendering<\/em> (CSR). Dabei \u00fcbernimmt der Browser die Verarbeitung und Darstellung der Inhalte. CSR bildet die Grundlage vieler moderner SPAs, beispielsweise Anwendungen auf Basis von React oder Vue.<\/p>\n\n\n\n

\u00c4hnlich wie bei SPAs l\u00e4dt der Browser zun\u00e4chst ein grundlegendes HTML-Dokument, anschlie\u00dfend die ben\u00f6tigten JavaScript-Dateien und f\u00fchrt diese aus. Dadurch wird die UI clientseitig aufgebaut, sodass Inhalte dynamisch geladen und dargestellt werden k\u00f6nnen.<\/p>\n\n\n\n

Dank CSR k\u00f6nnen UI-Aktualisierungen ohne vollst\u00e4ndiges Neuladen der Seite erfolgen. Allerdings ergeben sich \u00e4hnliche Herausforderungen wie bei klassischen SPAs, insbesondere hinsichtlich der lange Initialladezeiten und der SEO, da dynamisch erzeugte Inhalte f\u00fcr Suchmaschinen schwieriger zu indexieren sein k\u00f6nnen [12]<\/span>.<\/p>\n\n\n\n

2.2.3. Static Site Generation<\/h4>\n\n\n\n

Zur F\u00f6rderung schnellerer Ladezeiten werden bei der Static Site Generation<\/em> (SSG) Webseiten bereits w\u00e4hrend des Build-Prozesses erzeugt und nicht erst bei einer Anfrage serverseitig generiert. Die erzeugten statischen Dateien k\u00f6nnen anschlie\u00dfend in einem Content Delivery Network (CDN) gespeichert werden. Ein CDN beschreibt ein Netzwerk aus geografisch verteilten Servern zur effizienten und schnellen Auslieferung von Webinhalten [13]<\/span>.<\/p>\n\n\n\n

Nutzer erhalten dadurch die fertigen Seiten direkt von einem geografisch nahegelegenen CDN-Server. Allerdings besteht der Nachteil von SSG darin, dass Inhalte statisch sind und sich erst durch einen erneuten Build-Prozess aktualisieren. Daher ist dieser Ansatz weniger geeignet f\u00fcr Anwendungen mit h\u00e4ufig wechselnden oder Echtzeitdaten [12]<\/span>.<\/p>\n\n\n\n

2.2.4. Incremental Static Regeneration<\/h4>\n\n\n\n

Eine Kombination aus SSG und dynamischen Aktualisierungen bildet die Incremental Static Regeneration<\/em> (ISR). Dabei werden Seiten zun\u00e4chst statisch w\u00e4hrend des Build-Prozesses erzeugt und anschlie\u00dfend automatisch in definierten Intervallen aktualisiert. Hierf\u00fcr wird eine Revalidierungszeit festgelegt, nach deren Ablauf die Seite bei einer Nutzeranfrage im Hintergrund neu generiert wird. W\u00e4hrend dieses Prozesses wird weiterhin die bestehende Version aus dem Cache ausgeliefert (Cached Page Delivery), wodurch eine hohe Verf\u00fcgbarkeit gew\u00e4hrleistet wird. Dadurch k\u00f6nnen Inhalte jedoch f\u00fcr einen begrenzten Zeitraum veraltet sein. Zudem f\u00fchrt ISR insbesondere bei ULSSs zu einer h\u00f6heren technischen Komplexit\u00e4t [12]<\/span>.<\/p>\n\n\n\n

2.2.5. Edge Rendering<\/h4>\n\n\n\n

F\u00fcr das Rendering von Webanwendungen auf globaler Ebene spielt das Edge Rendering<\/em> eine wichtige Rolle. Dabei erfolgt das Rendering nicht zentral auf einem einzelnen Server, sondern auf Edge-Servern (auch Edge-Nodes genannt), die Teil eines verteilten Edge-Netzwerks sind und sich geografisch n\u00e4her am Nutzer befinden. Dadurch kann eine Nutzeranfrage an einem geeigneten, m\u00f6glichst nahegelegenen Edge-Server verarbeitet werden. Dort wird die Rendering-Logik ausgef\u00fchrt und das erzeugte HTML-Dokument direkt an den Nutzer zur\u00fcckgegeben [14]<\/span>.<\/p>\n\n\n\n

Im Unterschied zu einem CDN werden beim Edge Rendering nicht ausschlie\u00dflich bereits erzeugte statische Inhalte verteilt. W\u00e4hrend ein CDN haupts\u00e4chlich zur Zwischenspeicherung und Auslieferung vorhandener Inhalte dient, k\u00f6nnen beim Edge Rendering Inhalte dynamisch zur Laufzeit an der Edge erzeugt und anschlie\u00dfend ausgeliefert werden [13]<\/span>.<\/p>\n\n\n\n

2.2.6. Hybrid Rendering<\/h4>\n\n\n\n

Um die Kombination verschiedener Rendering-Methoden innerhalb derselben Anwendung zu erm\u00f6glichen, existiert das Hybrid Rendering<\/em>[15]<\/span>. Dabei k\u00f6nnen unterschiedliche Seiten oder Routen innerhalb derselben Anwendung mit unterschiedlichen Rendering-Strategien umgesetzt werden. Ein m\u00f6glicher Ansatz besteht darin, die initiale Seite serverseitig zu rendern (siehe SSR in Abschnitt 2.2.1<\/a>) und als fertiges HTML-Dokument auszuliefern, um eine schnelle initiale Darstellung sowie eine verbesserte SEO-Eignung zu erreichen. Anschlie\u00dfend \u00fcbernimmt der Browser die Ausf\u00fchrung von JavaScript und f\u00fchrt die sogenannte Hydration<\/em> durch, wodurch die statisch ausgelieferte Seite interaktiv wird [15][16]<\/span>.<\/p>\n\n\n\n

Die Hydration<\/em> beschreibt den Prozess, bei dem ein bereits serverseitig erzeugtes HTML-Dokument im Browser durch JavaScript mit interaktiver Logik und Event-Handlern erweitert wird [16]<\/span>.<\/p>\n\n\n\n

Anschlie\u00dfend k\u00f6nnen CSR-Mechanismen oder SPA-Ans\u00e4tze f\u00fcr dynamische und fl\u00fcssige Interaktionen genutzt werden, ohne dass ein vollst\u00e4ndiges Neuladen der Seite erforderlich ist [15]<\/span>.<\/p>\n\n\n\n

2.2.7. Auswahl eines Rendering-Ansatzes f\u00fcr das Web-Frontend im Uber-Kontext<\/h4>\n\n\n\n

Auf Basis der zuvor erl\u00e4uterten Rendering-Methoden werden geeignete Ans\u00e4tze f\u00fcr ein Web-Frontend im Uber-Kontext ausgew\u00e4hlt. Da keine einzelne Rendering-Methode alle Anforderungen des Systems vollst\u00e4ndig erf\u00fcllt, wird ein Ansatz des Hybrid Renderings verfolgt. Dabei basiert die Hauptanwendung auf einer SPA-Architektur in Kombination mit CSR, w\u00e4hrend statische und einstiegsorientierte Seiten durch SSR und SSG erg\u00e4nzt werden. Die Auswahl und Zuordnung der Rendering-Methoden f\u00fcr die einzelnen Anwendungsbereiche sind in Tabelle 1<\/a> dargestellt. Dabei wird ISR ausgeschlossen, da das Verfahren aufgrund der Revalidierungszeiten keine mit CSR vergleichbare Echtzeitf\u00e4higkeit erm\u00f6glicht und zudem in ULSSs zu einer erh\u00f6hten technischen Komplexit\u00e4t f\u00fchrt (siehe Abschnitt 2.2.4<\/a>).<\/p>\n\n\n\n

Methode<\/strong><\/th>Einsatz im System<\/strong><\/th>Begr\u00fcndung<\/strong><\/th><\/tr><\/thead>
SPA<\/td>Gesamtarchitektur der Haupt-Anwendung<\/td>Einmaliger Initial-Load, Navigation ohne\nReloads, Grundlage f\u00fcr Echtzeit-UI<\/td><\/tr>
CSR<\/td>Haupt-Anwendung (Karte, Tracking, Buchung,\nLive-UI)<\/td>Hohe Interaktivit\u00e4t und schnelle Updates\nf\u00fcr Echtzeit-Funktionen<\/td><\/tr>
SSR<\/td>Login, Einstieg, Marketing-Seiten<\/td>Schneller Initial-Load und bessere\nSEO-Unterst\u00fctzung<\/td><\/tr>
SSG<\/td>FAQ, Hilfe, statische Inhalte<\/td>Sehr schnelle Auslieferung statischer\nInhalte<\/td><\/tr>
Edge Rendering<\/td>SSR nahe am Nutzer<\/td>Reduzierte Latenz durch geografische\nN\u00e4he<\/td><\/tr><\/tbody><\/table>
Tabelle 1.<\/strong> Einsatz verschiedener Rendering-Methoden im Hybrid-Rendering Ansatz<\/figcaption><\/figure>\n\n\n\n

2.3. State Management<\/h3>\n\n\n\n

Ein State<\/em> bezeichnet im Frontend den aktuellen Zustand einer Anwendung und umfasst alle Daten, die sich w\u00e4hrend der Programmausf\u00fchrung \u00e4ndern k\u00f6nnen, beispielsweise Benutzereingaben, UI-Zust\u00e4nde oder Anwendungsdaten. Mit zunehmender Gr\u00f6\u00dfe und Komplexit\u00e4t einer Anwendung wird die Verwaltung dieser Zust\u00e4nde jedoch anspruchsvoller [17]<\/span>.<\/p>\n\n\n\n

Aus diesem Grund kommen Verfahren des State Managements<\/em> zum Einsatz, die eine strukturierte Verwaltung und Aktualisierung von States erm\u00f6glichen. State Management legt fest, wo sich ein State befindet, wie er ver\u00e4ndert wird und wie \u00c4nderungen innerhalb der Anwendung propagiert werden. Dadurch kann der Datenfluss vorhersehbarer gestaltet sowie die Nachvollziehbarkeit, Wartbarkeit und Skalierbarkeit einer Anwendung verbessert werden. Gleichzeitig wird das Risiko inkonsistenter Zust\u00e4nde und daraus resultierender Fehler reduziert [17]<\/span>.<\/p>\n\n\n\n

Grunds\u00e4tzlich lassen sich verschiedene Arten von States unterscheiden\n[18]<\/span>[17]<\/span>:<\/p>\n\n\n\n