{"id":29104,"date":"2026-07-31T17:30:00","date_gmt":"2026-07-31T15:30:00","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=29104"},"modified":"2026-07-31T15:42:30","modified_gmt":"2026-07-31T13:42:30","slug":"gewahrleistung-der-skalierbarkeit-eines-online-taxidienstes-am-beispiel-von-uber","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/07\/31\/gewahrleistung-der-skalierbarkeit-eines-online-taxidienstes-am-beispiel-von-uber\/","title":{"rendered":"Gew\u00e4hrleistung der Skalierbarkeit eines Online-Taxidienstes am Beispiel von Uber"},"content":{"rendered":"\n

Abstract:<\/strong> Skalierbarkeit geh\u00f6rt zu den zentralen Themen verteilter Systeme. Mit zunehmender Nachfrage und regionaler Ausbreitung eines verteilten Dienstes sind im Lauf der Zeit erhebliche Einschr\u00e4nkungen in der Leistung und Zuverl\u00e4ssigkeit zu erwarten. Insbesondere bei einem Taxidienst, dessen Dienste weltweit \u00fcber eine mobile Anwendung angeboten werden, m\u00fcssen spezifische technische Gegebenheiten wie Echtzeit\u00fcbertragung und die H\u00e4ufigkeit von Nutzeranfragen ber\u00fccksichtigt werden, um entsprechend angemessene Skalierungsma\u00dfnahmen zu treffen. F\u00fcr die Gew\u00e4hrleistung einer optimalen Leistung und Verf\u00fcgbarkeit unabh\u00e4ngig von der Nachfrage durch Endnutzer ist im Wesentlichen zu erkennen, dass eine klare Einteilung von Rollen, Verantwortlichkeiten und Ressourcen der verf\u00fcgbaren Hardware bez\u00fcglich geographischer und anwendungsinterner Zust\u00e4ndigkeiten unerl\u00e4sslich ist. F\u00fcr die Erforschung passender Skalierungstechniken werden verschiedene Techniken zur Skalierung eines verteilten Online-Taxivermittlungsdienstes am Beispiel des Taxidienstes Uber erl\u00e4utert und diskutiert.<\/p>\n\n\n\n

Index Terms:<\/strong> distributed systems, scalability, software architecture, sharding, partitioning, microservices<\/p>\n\n\n\n

I. Motivation<\/h2>\n\n\n\n

Skalierbarkeit z\u00e4hlt zu den zentralen Herausforderungen verteilter Systeme. Unternehmen, die verteilte Anwendungen kommerziell betreiben, besitzen ein wirtschaftliches Interesse, ihre Dienste in mehreren Regionen der Welt bereitzustellen, um eine m\u00f6glichst gro\u00dfe Nutzerbasis zu erreichen. Eine globale Verbreitung geht jedoch mit erheblichen technischen und wirtschaftlichen Herausforderungen einher. Insbesondere muss sichergestellt werden, dass die Anwendung auch bei einer hohen Anzahl gleichzeitiger Anfragen sowie einer gro\u00dfen Zahl beteiligter Server weiterhin eine geringe Antwortzeit aufweist.<\/p>\n\n\n\n

Im Kontext verteilter Systeme beschreibt Skalierbarkeit die F\u00e4higkeit einer Anwendung, mit zunehmender Last effizient umzugehen und ihre Leistungsf\u00e4higkeit durch den Einsatz zus\u00e4tzlicher Ressourcen aufrechtzuerhalten. Die architektonische Ausgestaltung eines skalierbaren Systems zielt darauf ab, auch bei einer stark steigenden Anzahl von Nutzeranfragen und einer weltweit verteilten Nutzerschaft kurze Antwortzeiten zu gew\u00e4hrleisten. Dabei soll verhindert werden, dass die Menge der Hardware-Ressourcen zu einem Engpass f\u00fcr die Leistung und Zuverl\u00e4ssigkeit des Systems werden.<\/p>\n\n\n\n

II. Grundlagen<\/h2>\n\n\n\n

In diesem Kapitel werden einige zentrale Aspekte von Skalierbarkeit zusammenfassend erkl\u00e4rt, die die Grundlage f\u00fcr das Verst\u00e4ndnis spezifischer Konzepte bilden.<\/p>\n\n\n\n

A. Horizontale und vertikale Skalierung<\/h3>\n\n\n\n

Ein zentrales Konzept der Skalierbarkeit ist die Unterscheidung zwischen horizontaler und vertikaler Skalierung. Diese beiden Ans\u00e4tze beschreiben unterschiedliche Methoden zur Steigerung der Leistungsf\u00e4higkeit einer verteilten Anwendung.<\/p>\n\n\n\n

1) Horizontale Skalierung<\/h4>\n\n\n\n

Unter horizontaler Skalierung wird die Erweiterung der verf\u00fcgbaren Hardware-Ressourcen durch die Erh\u00f6hung der Anzahl eingesetzter Rechner verstanden. Die Leistungsf\u00e4higkeit einer Anwendung wird dabei gesteigert, indem zus\u00e4tzliche Server in das System integriert werden. Dies erm\u00f6glicht nicht nur die Verteilung von Nutzeranfragen auf mehrere Server und damit die Reduzierung der Auslastung einzelner Systeme, sondern auch eine Reduktion der Latenz durch geographische Verteilung von Serverstandorten. Horizontale Skalierung bringt jedoch die Anforderung mit sich, die verteilten Systeme angemessen zu koordinieren, sodass in der Verarbeitung der Anfragen und dem Stand der Daten keine Inkonsistenzen entstehen. Dies umfasst beispielsweise die Weiterleitung von Anfragen an geeignete Serverinstanzen. In diesem Zusammenhang spielt das Konzept der Location Transparency eine wichtige Rolle: Die Verteilung der Anwendung soll f\u00fcr die Nutzer transparent bleiben, sodass das System trotz seiner verteilten Architektur als eine einzelne Anwendung wahrgenommen wird. [1]<\/p>\n\n\n\n

2) Vertikale Skalierung<\/h4>\n\n\n\n

Vertikale Skalierung bezeichnet die Leistungssteigerung eines einzelnen Rechners durch die Verbesserung seiner Hardwareausstattung. Eine Anwendung kann vertikal skaliert werden, indem leistungsf\u00e4higere Komponenten eingesetzt werden, wodurch die physischen Kapazit\u00e4ten des Host-Systems erh\u00f6ht werden. Dies kann verschiedene Hardware-Komponenten betreffen, darunter den Prozessor, den Arbeitsspeicher, sowie den persistenten Speicher. [1]<\/p>\n\n\n\n

Im Vergleich zur vertikalen Skalierung bietet die horizontale Skalierung in der Regel gr\u00f6\u00dfere Erweiterungsm\u00f6glichkeiten. Die vertikale Skalierung ist durch die Leistungsgrenzen der verf\u00fcgbaren Hardware beschr\u00e4nkt, da die Aufr\u00fcstung eines Systems nur solange m\u00f6glich ist, wie leistungsf\u00e4higere Komponenten zur Verf\u00fcgung stehen. Mit zunehmender Hardware-Leistung wird schlie\u00dflich ein Punkt erreicht, an dem keine weitere signifikante Verbesserung durch den Austausch einzelner Komponenten m\u00f6glich ist.<\/p>\n\n\n\n

Im weiteren Verlauf wird der Schwerpunkt auf der horizontalen Skalierung liegen. Die vertikale Skalierung ist zwar ebenfalls von Bedeutung und sollte nicht als irrelevant betrachtet werden, jedoch bieten horizontale Skalierungsans\u00e4tze in vielen Szenarien gr\u00f6\u00dfere Flexibilit\u00e4t und Erweiterungsm\u00f6glichkeiten. Auf die vertikale Skalierung wird dennoch zu einem sp\u00e4teren Zeitpunkt detaillierter eingegangen.<\/p>\n\n\n\n

B. Replizierung<\/h3>\n\n\n\n

Replizierung bezeichnet die mehrfache Bereitstellung einer Anwendungskomponente auf unterschiedlichen Servern. Dabei kann sich die Replizierung sowohl auf Daten, beispielsweise Dateien eines File-Hosting-Dienstes wie Google Drive, als auch auf die Anwendung selbst beziehen, indem ein Dienst parallel auf mehreren Servern ausgef\u00fchrt wird. [1]<\/p>\n\n\n\n

Daten werden repliziert, indem identische Datenbest\u00e4nde auf mehreren Speichermedien gleichzeitig vorgehalten werden. F\u00e4llt eines dieser Speichermedien aufgrund eines Defekts aus, bleiben die Daten weiterhin verf\u00fcgbar, da auf ein anderes Replika zur\u00fcckgegriffen werden kann. Dar\u00fcber hinaus dient die Replizierung dazu, Daten auf mehrere geographische Standorte zu verteilen und dadurch den Zugriff lokaler Server auf ben\u00f6tigte Daten zu beschleunigen. Dieses Prinzip l\u00e4sst sich nicht nur auf Daten, sondern ebenso auf Anwendungskomponenten anwenden. [1]<\/p>\n\n\n\n

Replizierung ist jedoch auch mit Herausforderungen verbunden. Insbesondere muss die Konsistenz zwischen den replizierten Daten gew\u00e4hrleistet werden. Dies erfordert zus\u00e4tzliche Anwendungslogik und verursacht einen entsprechenden Performance-Overhead. Zus\u00e4tzlich kann die f\u00fcr die Konsistenzsicherung verantwortliche Logik selbst zu einem Engpass in der Skalierung werden, da die zugrunde liegenden Algorithmen je nach Implementierung potentiell nur begrenzt skalierbar sind. W\u00e4hrend des Replizierungsprozesses muss sichergestellt werden, dass alle Replikas konsistent aktualisiert werden. Zudem ist festzulegen, wie mit Problemen in der Concurrency umgegangen wird, insbesondere in Situationen, in denen \u00c4nderungen an einem Replika vorgenommen werden, bevor fr\u00fchere Aktualisierungen auf allen anderen Replikas wirksam geworden sind. [1]<\/p>\n\n\n\n

C. CAP-Theorem im Kontext von Uber<\/h3>\n\n\n\n

Das CAP-Theorem besagt, dass in einem verteilten System die drei Eigenschaften Consistency, Availability und Partition Tolerance nicht gleichzeitig vollst\u00e4ndig gew\u00e4hrleistet werden k\u00f6nnen. Im Falle einer Netzwerkpartition kann ein System h\u00f6chstens zwei dieser Eigenschaften gleichzeitig erf\u00fcllen. [1]<\/p>\n\n\n\n

Die Architektur von Uber priorisiert grunds\u00e4tzlich Verf\u00fcgbarkeit und Partitionstoleranz. Weshalb dabei keine vollst\u00e4ndige Konsistenz gew\u00e4hrleistet werden kann, wird in Kapitel V-E bez\u00fcglich der Event-basierten Architektur n\u00e4her erl\u00e4utert. Im Zusammenhang mit geographischem Sharding (wie in Kapitel V-B beschrieben) wird zudem ersichtlich, dass eine globale Konsistenz \u00fcber verschiedene Regionen beziehungsweise Shards hinweg nicht zwingend erforderlich ist, da die Anwendung \u00fcberwiegend innerhalb der jeweiligen geographischen Region relevant ist. Die Gew\u00e4hrleistung von Konsistenz innerhalb eines einzelnen Shards stellt hingegen in der Regel kein wesentliches Problem dar, da die geographische N\u00e4he zwischen den beteiligten Systemen typischerweise zu geringen Latenzen f\u00fchrt.<\/p>\n\n\n\n

F\u00fcr s\u00e4mtliche Komponenten einer Anwendung muss nicht zwangsl\u00e4ufig dieselbe Auspr\u00e4gung des CAP-Theorems vorliegen. So kann die Datenbankschicht Konsistenz und Partitionstoleranz priorisieren, w\u00e4hrend die ereignisgetriebene Architektur auf Verf\u00fcgbarkeit und Partitionstoleranz ausgelegt ist.<\/p>\n\n\n\n

III. Anforderungen an die Funktion eines verteilten Taxidienstes<\/h2>\n\n\n\n

Im Folgenden werden Aspekte genannt, die zum Einen als allgemeine Anforderungen an die Architektur eines verteilten Taxidienstes verstanden werden k\u00f6nnen, und gleichzeitig den Grund f\u00fcr die Notwendigkeit von Skalierung darstellen.<\/p>\n\n\n\n

Konsistenz:<\/strong> Nutzerdaten m\u00fcssen schl\u00fcssig bleiben, selbst wenn der Nutzer in eine andere Region der Welt wechselt. [2]<\/p>\n\n\n\n

Aktualit\u00e4t der Daten:<\/strong> Neu erzeugte Datens\u00e4tze m\u00fcssen innerhalb von Sekunden vom Nutzer abrufbar sein. [2]<\/p>\n\n\n\n

Verf\u00fcgbarkeit:<\/strong> 99.99% Verf\u00fcgbarkeit muss in jeder geographischen Region, die vom Taxidienst abgedeckt wird, gew\u00e4hrleistet sein. [2]<\/p>\n\n\n\n

Kosten:<\/strong> Als Firma mit niedrigen Margen ist es insbesondere wichtig, Kosten zu sparen. [2]<\/p>\n\n\n\n

Latenz:<\/strong> Requests sollen h\u00f6chstens wenige Sekunden brauchen, um vom Server empfangen und verarbeitet zu werden. Im Gegenzug sollen Server-Antworten genauso lange brauchen, um beim Nutzer anzukommen. [2]<\/p>\n\n\n\n

Echtzeit:<\/strong> Uber muss Nutzern in Echtzeit Fahrer zuweisen. Somit ist Uber nicht nur eine verteilte Anwendung, sondern auch eine Echtzeitanwendung. [2]<\/p>\n\n\n\n

Die erw\u00e4hnten Anforderungen stellen indirekt zugleich die grundlegenden Ziele von Skalierung dar. Durch Skalierung werden Konsistenz, Aktualit\u00e4t, Verf\u00fcgbarkeit, Kosten, Latenz, und Echtzeit von der Anzahl der Nutzeranfragen und dem geographischen Ort eines konkreten Nutzers voneinander entkoppelt. Insbesondere der geographische Aspekt wird in den folgenden Kapiteln n\u00e4her erl\u00e4utert.<\/p>\n\n\n\n

IV. \u00dcbersicht \u00fcber den architektonischen Wandel des Taxidienstes Uber<\/h2>\n\n\n\n

In den Anfangsjahren bot Uber einen deutlich weniger umfangreichen Dienst an. Zum Zeitpunkt der Unternehmensgr\u00fcndung im Jahr 2009 beschr\u00e4nkte sich das Angebot ausschlie\u00dflich auf die Vermittlung von Taxifahrten und war zun\u00e4chst auf die Stadt San Francisco begrenzt. [3]<\/p>\n\n\n\n

Die urspr\u00fcngliche Uber-Anwendung war als monolithisches System konzipiert. Ein Monolith bezeichnet eine Softwareanwendung, die als eine einzige, zusammenh\u00e4ngende Einheit entwickelt, bereitgestellt und ausgef\u00fchrt wird. S\u00e4mtliche funktionalen Teilbereiche der Anwendung sind innerhalb derselben Codebasis integriert und weisen eine enge Kopplung auf. Monolithische Anwendungen sind daher weitgehend in sich geschlossen und f\u00fcr die Ausf\u00fchrung ihrer Kernfunktionalit\u00e4ten nicht auf externe Anwendungsdienste angewiesen. [4]<\/p>\n\n\n\n

Die urspr\u00fcngliche Implementierung des Uber-Taxidienstes bestand aus einem monolithischen PHP-Server, der eingehende Anfragen verarbeitete und entsprechende \u00c4nderungen in einer MySQL-Datenbank vornahm. Mit dem kontinuierlichen Wachstum der Nutzerbasis traten jedoch zunehmend Probleme im Zusammenhang mit konkurrierenden Zugriffen auf. Diese \u00e4u\u00dferten sich unter anderem darin, dass Nutzer unbeabsichtigt mehrere Fahrten gleichzeitig buchten oder einzelne Fahrer mehreren Kunden gleichzeitig zugewiesen wurden. [5]<\/p>\n\n\n\n

Im Jahr 2011 erfolgte die erste Aufteilung des urspr\u00fcnglichen Server-Monolithen in zwei separate Dienste: den Dispatcher und den API-Service. Der Dispatcher war f\u00fcr die Zuordnung von Fahrg\u00e4sten zu verf\u00fcgbaren Fahrern verantwortlich und wurde in Node.js implementiert. Der Einsatz einer ereignisbasierten, asynchronen Ausf\u00fchrungsumgebung stellte gegen\u00fcber dem vorherigen Ansatz einen wesentlichen Vorteil dar. Der Dispatcher kommunizierte mit einem API-Service, der weiterhin einen Gro\u00dfteil der Gesch\u00e4ftslogik der Anwendung enthielt, einschlie\u00dflich der Buchungs- und Zahlungsprozesse. Durch die Aufteilung in zwei Backend-Dienste erfolgte damit eine erste Ann\u00e4herung an eine serviceorientierte Architektur, wenngleich die Architektur noch deutlich von einer sp\u00e4teren Microservice-Landschaft entfernt war. [3]<\/p>\n\n\n\n

Mit dem weiteren Wachstum der Anwendung nahm auch der Aufwand f\u00fcr Build- und Bereitstellungsprozesse kontinuierlich zu. \u00c4nderungen an einzelnen Komponenten erforderten weiterhin die Neukompilierung und Bereitstellung der gesamten Anwendung. Parallel zum Wachstum der Nutzerbasis stieg auch die Anzahl der beteiligten Entwicklerinnen und Entwickler, wodurch sowohl Entwicklungs- als auch CI\/CD-Prozesse zunehmend komplexer, kostenintensiver und zeitaufw\u00e4ndiger wurden. Da monolithische Anwendungen grunds\u00e4tzlich als geschlossene Einheit gebaut und ausgef\u00fchrt werden, konnten diese Herausforderungen innerhalb der bestehenden Architektur nur begrenzt adressiert werden. Dies machte eine grundlegende Neugestaltung der Systemarchitektur erforderlich. [5]<\/p>\n\n\n\n

Im Jahr 2014 begann Uber mit der Migration zu einer Microservice-Architektur. Das zentrale Ziel bestand darin, die starke Kopplung einzelner Komponenten zu reduzieren, indem diese in eigenst\u00e4ndige Dienste ausgelagert wurden. [3] Die Einf\u00fchrung von Microservices f\u00fchrte zu grundlegenden Ver\u00e4nderungen sowohl in der Softwarearchitektur als auch im Entwicklungsprozess. Im Gegensatz zu einer rein logischen Modularisierung innerhalb eines Monolithen erm\u00f6glicht die Architektur eine physische Trennung einzelner Verantwortungsbereiche. Dar\u00fcber hinaus k\u00f6nnen die verschiedenen Dienste unabh\u00e4ngig voneinander entwickelt und in unterschiedlichen Programmiersprachen implementiert werden. Dies er\u00f6ffnet die M\u00f6glichkeit, technologiespezifische Optimierungen vorzunehmen und die verf\u00fcgbaren Hardwareressourcen effizienter auszunutzen. [3]<\/p>\n\n\n\n

Gleichzeitig bringt die Microservice-Architektur gegen\u00fcber einem monolithischen Ansatz zus\u00e4tzliche Herausforderungen mit sich. Insbesondere steigt die Komplexit\u00e4t des Gesamtsystems erheblich an. Dies betrifft nicht nur die Entwicklung der einzelnen Dienste, sondern auch Aspekte wie Sicherheit, Dienstkommunikation, Service-Discovery, Schnittstellenmanagement und System\u00fcberwachung. Im Bereich der Service-Discovery muss sichergestellt werden, dass eingehende Anfragen an die jeweils zust\u00e4ndigen Dienste weitergeleitet werden. Hierf\u00fcr sind zus\u00e4tzliche Mechanismen erforderlich, die die Lokalisierung und Adressierung der verf\u00fcgbaren Dienste erm\u00f6glichen. Bez\u00fcglich Security muss exakt bestimmt werden, welche Dienste von welchen Quellen per Schnittstelle kontaktiert werden k\u00f6nnen, um unbefugten und nicht vorgesehenen Datenzugriff zu vermeiden. Ein Beispiel eines solchen sicherheitskritischen Dienstes ist ein Payment-Service, der mit sensiblen Zahlungsinformationen arbeitet.<\/p>\n\n\n\n

Die Migration von monolithischen Systemen hin zu Microservice-Architekturen stellt ein Entwicklungsmuster vieler Anbieter gro\u00dfer verteilter Anwendungen dar. Ein weiteres bekanntes Beispiel hierf\u00fcr ist Netflix. [4] Bei einem neu gegr\u00fcndeten Anbieter eines Taxidienstes ist daher zu erwarten, dass die Anwendung eine \u00e4hnliche Entwicklung erleben wird. Dadurch, dass der Dienstanbieter betriebswirtschaftlich zun\u00e4chst eine finanzielle Grundlage aufbauen und die ersten Gewinnmargen ausreizen muss, erweitern sich damit entsprechend die technischen M\u00f6glichkeiten. Es ist daher riskant, das heutige Resultat des Wandels von Uber als eine allgemeine Blaupause f\u00fcr ein neu gegr\u00fcndetes Startup-Unternehmen zu betrachten. F\u00fcr ein Startup-Unternehmen ist einzusch\u00e4tzen, dass eine Microservice-Architektur einen zu hohen technischen und finanziellen Wartungsaufwand mit sich bringt, weshalb eine monolithische Architektur als eine nat\u00fcrliche, kostensparsame Alternative f\u00fcr die initiale Phase der Entwicklung folgt.<\/p>\n\n\n\n

V. Techniken zur Gew\u00e4hrleistung der Skalierbarkeit<\/h2>\n\n\n\n

In den folgenden Unterkapiteln werden verschiedene Techniken vorgestellt, die zur Skalierbarkeit verteilter Anwendungen beitragen. Die meisten dieser Techniken sind jedoch nicht ausschlie\u00dflich dem Fachgebiet der verteilten Systeme zuzuordnen, sondern stellen allgemeine Konzepte der Informatik dar, die in unterschiedlichen Arten von Softwareanwendungen Anwendung finden.<\/p>\n\n\n\n

A. Zustandslosigkeit<\/h3>\n\n\n\n

Zustandslose Server zeichnen sich dadurch aus, dass die Verarbeitung einer Anfrage nicht vom internen Zustand der Anwendung abh\u00e4ngt. Vorangegangene Interaktionen beeinflussen das Ergebnis zuk\u00fcnftiger Interaktionen, beispielsweise in Form von Transaktionen oder API-Aufrufen, nicht unmittelbar. Jede Anfrage kann daher als isolierte Einheit betrachtet werden. Zustandslosigkeit f\u00fchrt zwar nicht zwangsl\u00e4ufig zu deterministischen Ergebnissen, da externe Zustandsquellen wie Datenbanken weiterhin Einfluss auf die Verarbeitung nehmen k\u00f6nnen, sie erh\u00f6ht jedoch die Vorhersagbarkeit des Systemverhaltens. Der Grund hierf\u00fcr liegt darin, dass kein innerhalb der Anwendung gespeicherter Zustand zur Beeinflussung der Anfrageverarbeitung herangezogen wird.<\/p>\n\n\n\n

Da der betrachtete Taxidienst die Verarbeitung von Echtzeitdaten erfordert, kann nicht jede Komponente der Anwendung zustandslos realisiert werden. Ein naheliegendes Beispiel stellt die Echtzeitverfolgung eines bestellten Taxis dar. Um Positionsdaten in kurzen zeitlichen Intervallen an Nutzer zu \u00fcbermitteln, ist eine Architektur erforderlich, die \u00fcber klassische zustandslose Kommunikation per Anfrage und Antwort hinausgeht. Hierf\u00fcr eignen sich insbesondere streamingbasierte Kommunikationsans\u00e4tze, bei denen Daten kontinuierlich \u00fcbertragen werden, anstatt ausschlie\u00dflich \u00fcber diskrete API-Aufrufe zu festgelegten Zeitpunkten ausgetauscht zu werden.<\/p>\n\n\n\n

B. Geographische Skalierung durch Sharding<\/h3>\n\n\n\n

Uber bietet seine Dienste in zahlreichen Staaten und \u00fcber mehrere Kontinente hinweg an. Daraus ergeben sich  gro\u00dfe regionale Schwankungen hinsichtlich Bev\u00f6lkerungszahl, Bev\u00f6lkerungsdichte und Verkehrsaufkommen der bedienten Regionen. Unter diesen Voraussetzungen ist es nicht mehr ausreichend, s\u00e4mtliche Nutzeranfragen unabh\u00e4ngig von ihrer geographischen Herkunft \u00fcber dasselbe Rechenzentrum zu verarbeiten.<\/p>\n\n\n\n

Sharding bezeichnet eine Skalierungstechnik, bei der die Gesamtheit der Daten und\/oder Aufgaben einer Anwendung auf mehrere Server verteilt wird. [6] Die Architektur von Uber basiert stark auf dem Prinzip des Shardings, indem zahlreiche Prozesse, wie unter anderem Preisanpassung \u00fcber Surge Pricing, auf Sharding-Strategien beruhen.<\/p>\n\n\n\n

Das Anfrageaufkommen der Uber-Dienste unterscheidet sich erheblich zwischen einzelnen Regionen. In Gro\u00dfst\u00e4dten ist mit einem deutlich h\u00f6heren Verkehrsaufkommen zu rechnen als in l\u00e4ndlichen Gebieten. Dar\u00fcber hinaus bestehen auch zwischen Staaten, Provinzen oder anderen Verwaltungseinheiten erhebliche Unterschiede hinsichtlich der durchschnittlichen Auslastung. Unter diesen Voraussetzungen ist es wenig zweckm\u00e4\u00dfig, s\u00e4mtliche Anfragen \u00fcber ein gemeinsames Rechenzentrum zu verarbeiten, da Regionen mit hohem Anfrageaufkommen die verf\u00fcgbaren Ressourcen \u00fcberlasten und dadurch auch Regionen mit geringerem Verkehrsaufkommen beeintr\u00e4chtigen k\u00f6nnen.<\/p>\n\n\n\n

In diesem Fall bietet es sich an, die verf\u00fcgbaren Host-Systeme gezielt einzelnen geographischen Regionen zuzuordnen.<\/p>\n\n\n\n

Da f\u00fcr die Nutzer eines Taxidienstes in erster Linie das unmittelbare geographische Umfeld relevant ist und nicht das weltweite Gesamtsystem, ist eine globale Verarbeitung s\u00e4mtlicher Anfragen nicht erforderlich. Daraus ergibt sich die M\u00f6glichkeit, den geographischen Zust\u00e4ndigkeitsbereich einzelner Systemkomponenten gezielt zu begrenzen und die vorhandenen Hardwareressourcen auf bestimmte Regionen zu spezialisieren.<\/p>\n\n\n\n

F\u00fcr die Umsetzung von geographischem Sharding werden geographische Gebiete, beispielsweise St\u00e4dte oder Metropolregionen, in einzelne Regionen beziehungsweise Zonen unterteilt, denen jeweils dedizierte Server zugeordnet sind. Jeder Server beziehungsweise jedes Servercluster \u00fcbernimmt dabei die Verarbeitung der Anfragen einer bestimmten geographischen Region. Nutzer werden anhand ihres aktuellen geographischen Standorts einem entsprechenden Shard zugeordnet, wodurch eindeutig bestimmt werden kann, welche Server f\u00fcr die Verarbeitung ihrer Anfragen zust\u00e4ndig sind. Durch diese regionale Zuordnung k\u00f6nnen Hardwareressourcen bedarfsgerecht bereitgestellt werden, da die zust\u00e4ndigen Systemadministratoren den Ressourcenbedarf einzelner Regionen absch\u00e4tzen und bei der Infrastrukturplanung ber\u00fccksichtigen k\u00f6nnen.<\/p>\n\n\n\n

Dar\u00fcber hinaus tr\u00e4gt Sharding zur Ausfallsicherheit bei, da Sharding die Infrastruktur von Uber stark dezentralisiert. Ein Ausfall einer Stadt beziehungsweise einer geographischen Region soll keine anderen unverwandten Regionen auf der Welt beeinflussen.<\/p>\n\n\n\n

Das Prinzip des geographischen Shardings findet sich auch au\u00dferhalb der Informatik. Ein anschauliches Beispiel stellt die Einteilung eines Staatsgebietes in Wahlbezirke dar. In westlichen Demokratien ist es \u00fcblich, dass aus jedem Wahlbezirk ein Abgeordneter in das nationale Parlament entsandt wird. Damit Wahlen m\u00f6glichst gleichberechtigte Voraussetzungen f\u00fcr alle Wahlberechtigten und Parteien schaffen, wird angestrebt, dass die Wahlbezirke jeweils eine vergleichbare Anzahl an wahlberechtigten Einwohnern umfassen. Dieses Prinzip kann als politische Analogie zur gleichm\u00e4\u00dfigen Auslastung einzelner Regionen verstanden werden. Wahlbezirke gew\u00e4hrleisten dar\u00fcber hinaus, dass regionale Interessen im Parlament repr\u00e4sentiert werden, indem jede Region einen eigenen Abgeordneten w\u00e4hlt. W\u00fcrde ein Staat hypothetisch nur aus einem einzigen Wahlbezirk bestehen, w\u00fcrde lediglich eine Partei den Wahlkreis gewinnen und dadurch mit einem einzigen Sitz zu 100% im Parlament vertreten sein, obwohl ihr tats\u00e4chlicher Stimmenanteil mit hoher Wahrscheinlichkeit deutlich unter 100% liegt. Die Unterteilung in mehrere Wahlbezirke erm\u00f6glicht somit eine differenzierte regionale Repr\u00e4sentation. In Abbildung 1 ist eine Wahlbezirkskarte dargestellt, anhand der sich das Prinzip der regionalen Unterteilung eines Gesamtsystems veranschaulichen l\u00e4sst. Dieses Grundprinzip l\u00e4sst sich in weiten Teilen auf die Infrastruktur von Uber \u00fcbertragen. Anstatt s\u00e4mtliche Anfragen unabh\u00e4ngig von ihrer geographischen Herkunft durch dieselbe Infrastruktur zu verarbeiten und dadurch eine \u00dcberlastung einzelner Komponenten zu riskieren, werden Server beziehungsweise Servercluster gezielt bestimmten geographischen Regionen zugeordnet. Die Bereitstellung der Hardwareressourcen kann dadurch an das jeweilige regionale Anfrageaufkommen angepasst werden. Grunds\u00e4tzlich bewirkt das Prinzip des Shardings daher, dass regionale Probleme mit regionalen, auf den konkreten Ort angepassten Mitteln gel\u00f6st werden.<\/p>\n\n\n\n


<\/p>\n\n\n\n

\"\"<\/a>
Fig. 1. Karte der Wahlbezirke in Gro\u00dfbritannien, gef\u00e4rbt nach der Partei, die in den Parlamentswahlen des Jahres 2024 im jeweiligen Wahlbezirk die relative Mehrheit erlangte. Quelle: https:\/\/commons.wikimedia.org\/wiki\/File:2024_United_Kingdom_general_election_-_Result.svg (letzter Zugriff: 31. Juli 2026)<\/figcaption><\/figure>\n\n\n\n

Es muss beachtet werden, dass f\u00fcr diese Sharding-Strategie kein einheitlicher Konsens \u00fcber den Namen herrscht. Sharding ist nur eine von mehreren M\u00f6glichkeiten, die Technik zu nennen, und bezeichnet das Einteilen von geographischen Regionen in Teilregionen zur effizienteren Zuweisung und Auslastung von Hardware. Sharding beantwortet lediglich die Frage, welcher Region welche technischen Ressourcen zugewiesen werden und welche anwendungsbezogenen Entit\u00e4ten, wie beispielsweise Taxifahrer, f\u00fcr welchen Nutzer relevant sind. Andere Quellen k\u00f6nnen stattdessen unter anderem Begriffe wie Partitionierung oder Aufteilung verwenden.<\/p>\n\n\n\n

Mit der Implementierung von geographischem Sharding ergeben sich mehrere weitere Fragestellungen. Hierzu geh\u00f6ren beispielsweise die Kriterien f\u00fcr die Bestimmung der r\u00e4umlichen Gr\u00f6\u00dfe und Anzahl der Regionen. Dabei soll insbesondere die Bev\u00f6lkerungszahl und die regionale Nachfrage der Taxidienste ber\u00fccksichtigt werden. Ebenfalls muss festgelegt werden, welche Bedingungen eine Neuzuweisung der regionalen Ausbreitung eines Shards voraussetzen. Dar\u00fcber hinaus ist zu bestimmen, welche Daten ausschlie\u00dflich innerhalb eines bestimmten Shards relevant sind, beispielsweise Echtzeitdaten laufender Taxifahrten, und welche Daten unabh\u00e4ngig von einer geographischen Region gespeichert werden k\u00f6nnen, wie etwa Reisehistorien oder Zahlungsinformationen von Nutzern. Schlie\u00dflich stellt sich die Frage nach der Platzierung der Host-Server, die einem bestimmten Shard zugeordnet sind. Dabei muss ber\u00fccksichtigt werden, dass die physische Infrastruktur wom\u00f6glich nicht jederzeit am geographischen Standort des jeweiligen Shards zur Verf\u00fcgung stehen wird.<\/p>\n\n\n\n

Die Festlegung geeigneter geographischer Shards stellt insbesondere deshalb eine Herausforderung dar, weil zwischen st\u00e4dtischen und l\u00e4ndlichen Regionen unterschieden werden muss. Aufgrund des deutlich h\u00f6heren Verkehrs- und Anfrageaufkommens in Gro\u00dfst\u00e4dten bietet es sich an, diese als eigenst\u00e4ndige Regionen zu behandeln, w\u00e4hrend das umliegende l\u00e4ndliche Gebiet zu einer separaten Region zusammengefasst wird. Da die Bev\u00f6lkerungsdichte je nach Region erheblich variiert, ist es zweckm\u00e4\u00dfig, l\u00e4ndliche Gebiete in fl\u00e4chenm\u00e4\u00dfig gr\u00f6\u00dfere Regionen einzuteilen als dicht besiedelte Ballungsr\u00e4ume. Besteht das Ziel darin, die Regionen so zu dimensionieren, dass sie jeweils eine vergleichbare Bev\u00f6lkerungszahl umfassen, ergibt sich daraus zwangsl\u00e4ufig, dass l\u00e4ndliche Regionen eine deutlich gr\u00f6\u00dfere geographische Ausdehnung besitzen als st\u00e4dtische Regionen mit hoher Bev\u00f6lkerungsdichte. In Abbildung 2 wird dieses Prinzip anhand der administrativen Provinzeinteilung Algeriens veranschaulicht. Aufgrund der klimatischen Gegebenheiten weist Algerien eine stark ungleichm\u00e4\u00dfige Bev\u00f6lkerungsverteilung auf. W\u00e4hrend die n\u00f6rdliche Mittelmeerk\u00fcste dicht besiedelt ist und entsprechend in zahlreiche fl\u00e4chenm\u00e4\u00dfig kleine Provinzen unterteilt wird, umfassen die zentralen und s\u00fcdlichen Landesteile \u00fcberwiegend W\u00fcstengebiete mit geringer Bev\u00f6lkerungsdichte. Dementsprechend besitzen die s\u00fcdlichen Provinzen eine erheblich gr\u00f6\u00dfere territoriale Ausdehnung als die Provinzen entlang der Mittelmeerk\u00fcste. Dieses Muster entspricht dem bereits anhand der Wahlbezirke erl\u00e4uterten Prinzip einer regionalen Unterteilung entsprechend der jeweiligen Bev\u00f6lkerungsdichte.<\/p>\n\n\n\n

\"\"<\/a>
Fig. 2. Karte der regionalen Unterteilung von Algerien im Stand von 2019. Quelle: https:\/\/de.wikipedia.org\/wiki\/Datei:Algeria,_administrative_divisions_2019_-_de_-_colored.svg (letzter Zugriff: 31. Juli 2026)<\/figcaption><\/figure>\n\n\n\n

Nicht alle Daten m\u00fcssen einer konkreten geographischen Region zugeordnet werden. Je nach Art der gespeicherten Informationen eignen sich unterschiedliche Sharding-Strategien. Echtzeitdaten sollten grunds\u00e4tzlich innerhalb des jeweiligen Shards gespeichert werden, da sie sich auf aktuelle Zustands\u00e4nderungen laufender Taxifahrten beziehen und \u00fcberwiegend f\u00fcr die jeweilige Region relevant sind. Allgemeine Nutzerdaten, wie beispielsweise Namen oder Zahlungsinformationen, k\u00f6nnen hingegen unabh\u00e4ngig von einer geographischen Region gespeichert werden. Alternativ k\u00f6nnen sie aus Optimierungsgr\u00fcnden dem jeweiligen Shard eines Nutzers zugeordnet werden.<\/p>\n\n\n\n

Dar\u00fcber hinaus muss ber\u00fccksichtigt werden, dass physische Server nicht zwangsl\u00e4ufig innerhalb der geographischen Region betrieben werden k\u00f6nnen, der sie logisch zugeordnet sind. Insbesondere kurzfristige Nachfragespitzen, beispielsweise infolge gr\u00f6\u00dferer Veranstaltungen, k\u00f6nnen dazu f\u00fchren, dass die in einer Region verf\u00fcgbaren Ressourcen nicht mehr ausreichen. Um in solchen Situationen nicht auf weit entfernte Host-Systeme zur\u00fcckgreifen zu m\u00fcssen, sollte die Infrastruktur in der Lage sein, innerhalb des weltweiten Serverbestands zun\u00e4chst nach geographisch m\u00f6glichst nahegelegenen verf\u00fcgbaren Systemen zu suchen und diese gegebenenfalls einem neuen oder erweiterten Shard zuzuordnen.<\/p>\n\n\n\n

C. Horizontale Skalierung<\/h3>\n\n\n\n

Neben der Umsetzung allgemeiner Optimierungsstrategien wie geographischer Zoneneinteilung, Load Balancing und der Optimierung von CPU-Laufzeiten ist zus\u00e4tzlich ein Mechanismus erforderlich, der eine effektive horizontale Skalierung der zugrunde liegenden Hardware erm\u00f6glicht. Geographisches Sharding tr\u00e4gt zwar zur Entlastung der Gesamtinfrastruktur bei, indem Hardware-Ressourcen bestimmten geographischen Regionen zugeordnet werden und dadurch die Last entsprechend verteilt wird, jedoch reicht die reine Zoneneinteilung nicht aus, um Leistungseinbu\u00dfen w\u00e4hrend Spitzenlastzeiten angemessen zu minimieren. Auch innerhalb eines einzelnen Shards k\u00f6nnen erhebliche Lastschwankungen auftreten. Daher wird ein Verfahren ben\u00f6tigt, das es erm\u00f6glicht, bei steigendem Ressourcenbedarf innerhalb kurzer Zeit zus\u00e4tzliche Infrastruktur bereitzustellen und dem betroffenen Shard zuzuweisen.<\/p>\n\n\n\n

Die Zustandslosigkeit der Server vereinfacht den Skalierungsprozess erheblich, da das Verhalten eines Dienstes nicht vom internen Zustand des jeweiligen Dienstes abh\u00e4ngt, sondern ausschlie\u00dflich von externen Datenquellen, insbesondere relationalen Datenbanken. Dadurch kann leichter sichergestellt werden, dass mehrfach instanziierte Dienste ein konsistentes und vorhersagbares Verhalten aufweisen.<\/p>\n\n\n\n

Uber verwendet hierzu einen Machine-Learning-basierten Algorithmus, die Capacity Recommendation Engine, der auf Grundlage historischer Daten Vorhersagen \u00fcber den zuk\u00fcnftigen Kapazit\u00e4tsbedarf trifft (Peak Throughput Estimation). Der Algorithmus fungiert somit als Mechanismus zur automatischen Skalierung und unterst\u00fctzt sowohl die dynamische Erweiterung als auch die Reduzierung der verf\u00fcgbaren Infrastrukturressourcen. [7]<\/p>\n\n\n\n

Eine zentrale Herausforderung besteht darin, den erforderlichen Gesamtbestand an Hardware-Ressourcen so zu bestimmen, dass in allen Shards mit erh\u00f6htem Ressourcenbedarf ausreichend Kapazit\u00e4ten f\u00fcr Skalierungsma\u00dfnahmen zur Verf\u00fcgung stehen, ohne dass hierf\u00fcr Ressourcen aus anderen Shards abgezogen werden m\u00fcssen.<\/p>\n\n\n\n

D. Vertikale Skalierung der CPU-Rechenzeit<\/h3>\n\n\n\n

Physische Server, auf denen Uber-Dienste ausgef\u00fchrt werden, verf\u00fcgen \u00fcber Prozessoren mit einer festen Anzahl von CPU-Kernen. Da sowohl die Anzahl der gleichzeitig ausgef\u00fchrten Dienste als auch deren Ressourcenbedarf erheblichen Schwankungen unterliegen, ist es aus Sicht der Ressourceneffizienz nicht sinnvoll, s\u00e4mtlichen Diensten dauerhaft den Zugriff auf alle verf\u00fcgbaren CPU-Ressourcen zu gew\u00e4hren. Eine solche \u00dcberprovisionierung f\u00fchrt zu unn\u00f6tigem Energieverbrauch und erh\u00f6hten Betriebskosten, obwohl ein erheblicher Teil der bereitgestellten Ressourcen zeitweise ungenutzt bleibt. [8]<\/p>\n\n\n\n

\u00dcber einen l\u00e4ngeren Zeitraum erfolgte die CPU-Provisionierung bei Uber manuell durch die zust\u00e4ndigen Systemadministratoren. Die f\u00fcr einzelne Dienste und deren Infrastruktur verantwortlichen Teams mussten die Ressourcenzuweisung regelm\u00e4\u00dfig anpassen, um auf Ver\u00e4nderungen der Systemauslastung reagieren zu k\u00f6nnen. [8]<\/p>\n\n\n\n

Ziel der CPU-Provisionierung ist die bedarfsgerechte Zuweisung von CPU-Ressourcen an einzelne Container. Dabei sollen m\u00f6glichst wenige Ressourcen reserviert werden, ohne die Leistungsf\u00e4higkeit oder Reaktionszeiten der Anwendung merklich zu beeintr\u00e4chtigen. Dies setzt ein Verfahren voraus, das den tats\u00e4chlichen Ressourcenbedarf m\u00f6glichst pr\u00e4zise bestimmen kann. [8]<\/p>\n\n\n\n

Eine zentrale Herausforderung besteht darin, zun\u00e4chst zu ermitteln, ob die verf\u00fcgbare Hardware ausreichende CPU-Kapazit\u00e4ten f\u00fcr einen bestimmten Workload bereitstellen kann und in welchem Umfang CPU-Ressourcen einem Container zugewiesen werden k\u00f6nnen. Die Ressourcenzuweisung erfordert daher eine vorgelagerte Analyse der verf\u00fcgbaren Hardwarekapazit\u00e4ten. Ohne eine entsprechende Planung besteht die Gefahr eines schwer vorhersehbaren Laufzeitverhaltens, da unterschiedliche Hardwarekonfigurationen bei einer Neuzuweisung zu abweichenden Leistungsmerkmalen f\u00fchren k\u00f6nnen. [8]<\/p>\n\n\n\n

Eine weitere Herausforderung ergibt sich aus den erheblichen Schwankungen der Systemauslastung im Verlauf einer Woche. Werden die zugewiesenen CPU-Ressourcen nicht regelm\u00e4\u00dfig und zeitnah an den tats\u00e4chlichen Bedarf angepasst, verbleiben Workloads \u00fcber l\u00e4ngere Zeitr\u00e4ume in einem \u00fcberprovisionierten Zustand. Dies f\u00fchrt zu einer ineffizienten Nutzung der verf\u00fcgbaren Infrastrukturressourcen und zu erh\u00f6hten Energiekosten beim Infrastrukturbetrieb. [8]<\/p>\n\n\n\n

Dar\u00fcber hinaus kann die Verlagerung von Workloads zwischen unterschiedlichen Rechnern einen erheblichen Zeitaufwand verursachen und unter Umst\u00e4nden mehrere Stunden in Anspruch nehmen. Aus diesem Grund sollten Strategien vermieden werden, die eine h\u00e4ufige Umverteilung von Ressourcen zwischen verschiedenen Systemen erfordern. [8]<\/p>\n\n\n\n

E. Event-basierte Architektur<\/h3>\n\n\n\n

In einer ereignisgetriebenen Architektur (Event-driven Architecture) werden Funktionen nicht durch direkte Funktionsaufrufe innerhalb des Quellcodes ausgel\u00f6st. Stattdessen werden sie an bestimmte Ereignisse (Events) gekoppelt und durch den Empfang entsprechender Benachrichtigungen aktiviert. Die Ausf\u00fchrung einer Funktion erfolgt somit, sobald ein zugeh\u00f6riges Event signalisiert, dass ein bestimmtes Ereignis eingetreten ist.<\/p>\n\n\n\n

Ereignisgetriebene Architekturen dienen dazu, lose gekoppelte Dienste miteinander zu verkn\u00fcpfen. Da die Verarbeitung von Ereignissen \u00fcber definierte Event Listener erfolgt, k\u00f6nnen neue Verarbeitungsschritte hinzugef\u00fcgt oder bestehende entfernt werden, ohne dass umfangreiche \u00c4nderungen am Quellcode eines Dienstes erforderlich sind. Dies tr\u00e4gt zur Entkopplung einzelner Systemkomponenten bei und erleichtert die Erweiterbarkeit der Gesamtarchitektur. [9]<\/p>\n\n\n\n

Ein Event repr\u00e4sentiert ein beliebiges Ereignis innerhalb der Anwendung. Im Kontext von Uber k\u00f6nnen dies beispielsweise die Erstellung eines Nutzerkontos oder die Buchung einer Taxifahrt sein.<\/p>\n\n\n\n

Eine h\u00e4ufig eingesetzte Form der Event-Architektur ist die Publisher-Subscriber-Architektur. Ein Publisher erzeugt und ver\u00f6ffentlicht Ereignisse, w\u00e4hrend Subscriber diese Ereignisse empfangen und darauf reagieren. Die Kommunikation erfolgt dabei indirekt \u00fcber eine vermittelnde Infrastruktur, sodass Publisher und Subscriber nicht unmittelbar voneinander abh\u00e4ngig sind. Dadurch k\u00f6nnen unterschiedliche Dienste dieselben Ereignisse verarbeiten und jeweils eigene Anwendungslogik ausf\u00fchren. Ein Dienst kann dabei sowohl Ereignisse ver\u00f6ffentlichen als auch Ereignisse anderer Dienste verfolgen.<\/p>\n\n\n\n

F\u00fcr eine Anwendung wie Uber eignen sich ereignisgetriebene Architekturen insbesondere aufgrund der Anforderungen an die zeitnahe Verarbeitung von Zustands\u00e4nderungen. Beispiele hierf\u00fcr sind die \u00dcbermittlung von Standortinformationen eines Fahrzeugs oder Statusaktualisierungen einer laufenden Fahrt. Obwohl es sich dabei in der Regel nicht um ein tats\u00e4chliches Echtzeitsystem handelt, sondern lediglich um Aktualisierungen in regelm\u00e4\u00dfigen Zeitintervallen, erm\u00f6glicht die Event-Architektur eine kontinuierliche Verteilung aktueller Informationen an die beteiligten Komponenten. Auf diese Weise kann die mobile Anwendung fortlaufend den aktuellen Zustand einer Fahrt oder die Position eines Fahrzeugs abrufen und darstellen.<\/p>\n\n\n\n

Neben den Komponenten zur Erzeugung und Verarbeitung von Ereignissen ist zus\u00e4tzlich ein Mechanismus zur \u00dcbermittlung der Events erforderlich. Die Einf\u00fchrung einer ereignisgetriebenen Architektur macht daher die Auswahl eines geeigneten Kommunikationsmodells notwendig. Dabei stellt sich insbesondere die Frage, ob Ereignisse als einzelne Nachrichten an die jeweiligen Empf\u00e4nger \u00fcbertragen werden sollen oder ob sie als kontinuierlicher Datenstrom bereitgestellt und dauerhaft gespeichert werden. Die Wahl des Kommunikationsmodells hat wesentlichen Einfluss auf Skalierbarkeit, Fehlertoleranz, Nachvollziehbarkeit von Ereignissen sowie die M\u00f6glichkeiten der sp\u00e4teren Datenanalyse.<\/p>\n\n\n\n

Aufgrund der hohen Anforderungen bez\u00fcglich Echtzeit sowie der komplexen Prozesse bei einem Taxidienst eignet sich im gegebenen Anwendungsfall insbesondere das Streaming-Modell. Durch das kontinuierliche \u00dcbertragen von Events werden einzelne Ereignisse nach der Verarbeitung nicht verworfen, sondern es kann ein Protokoll eingegangener Ereignisse archiviert werden, wodurch bereits verarbeitete Events jederzeit abrufbar bleiben. Die Speicherdauer von Eventprotokollen kann zudem durch den Systemadministrator konfiguriert werden, wodurch der Speicheraufwand des Event-Stream-Ansatzes flexibel bleibt. Durch die kleinere Gr\u00f6\u00dfe des Payloads bei Event Streams ist zus\u00e4tzlich eine Verarbeitung viel gr\u00f6\u00dferer Mengen an Events pro Zeiteinheit m\u00f6glich [10], was f\u00fcr einen verteilten Taxidienst, bei dem Taxibestellungen bereits pro Stunde h\u00e4ufig auftreten, von Vorteil ist. Apache Kafka ist ein Beispiel einer Technologie, die den Zweck erf\u00fcllt, Event-Streaming in einer Anwendung umzusetzen.<\/p>\n\n\n\n

Die ereignisgetriebene Architektur ist im Kontext der Skalierbarkeit insofern relevant, dass durch diese Architektur der Entwicklungsaufwand auf der Seite des Unternehmens bedeutend sinkt, wodurch Dienste effektiver entwickelt, modifiziert und entfernt werden k\u00f6nnen. Das Gesamtnetzwerk aller betriebenen Dienste wird damit flexibler und leichter ver\u00e4nderbar, wodurch ein laufender Betrieb des Taxidienstes f\u00fcr die Nutzerseite leichter garantiert werden kann.<\/p>\n\n\n\n

F. Load Balancing<\/h3>\n\n\n\n

Die Implementierung von geographischem Sharding und horizontaler Skalierung allein gen\u00fcgt nicht, um geringe Latenzen bei Nutzeranfragen sicherzustellen. Auch innerhalb eines einzelnen Shards kann es zu einer \u00dcberlastung der Backend-Dienste kommen. Dies kann beispielsweise auftreten, wenn ein Shard eine Gro\u00dfstadt repr\u00e4sentiert und aufgrund einer gr\u00f6\u00dferen Veranstaltung eine erh\u00f6hte Nachfrage nach Taxifahrten entsteht. In solchen Situationen muss die Infrastruktur auch innerhalb des betroffenen Shards horizontal skaliert und die Netzwerklast gleichm\u00e4\u00dfig auf die verf\u00fcgbaren Host-Systeme verteilt werden.<\/p>\n\n\n\n

Die Verteilung einer gro\u00dfen Anzahl eingehender Anfragen auf mehrere Host-Systeme wird als Load Balancing bezeichnet. Load Balancing wird \u00fcblicherweise durch einen dedizierten Dienst oder eine spezialisierte Anwendung realisiert. Ziel ist es, einzelne Server zu entlasten, indem die Gesamtheit der eingehenden Nutzeranfragen auf mehrere Rechner verteilt wird. Dadurch wird nicht nur die Netzwerkauslastung einzelner Systeme reduziert, sondern auch eine effizientere Nutzung der verf\u00fcgbaren Rechenressourcen erreicht. [11]<\/p>\n\n\n\n

Mit dem Einsatz von Load Balancing werden insbesondere zwei Ziele verfolgt: die Steigerung der Zuverl\u00e4ssigkeit und die Verbesserung der Ressourceneffizienz. Werden Anfragen nicht gleichm\u00e4\u00dfig auf die verf\u00fcgbaren Systeme verteilt, k\u00f6nnen einzelne Rechner \u00fcberlastet werden, was zu erh\u00f6hten Antwortzeiten und damit zu einer Beeintr\u00e4chtigung der Anwendungsleistung f\u00fchrt. Gleichzeitig wird die vorhandene Infrastruktur ineffizient genutzt, da potentiell zus\u00e4tzliche Hardware bereitgestellt wird, obwohl bereits laufende Systeme noch \u00fcber ungenutzte Kapazit\u00e4ten verf\u00fcgen. Load Balancing tr\u00e4gt daher dazu bei, die vorhandenen Ressourcen m\u00f6glichst vollst\u00e4ndig auszusch\u00f6pfen, bevor eine Erweiterung der Infrastruktur erforderlich wird.<\/p>\n\n\n\n

Dar\u00fcber hinaus erh\u00f6ht Load Balancing die Ausfallsicherheit eines Systems. F\u00e4llt ein einzelner Rechner aus, k\u00f6nnen eingehende Anfragen weiterhin auf die verbleibenden Systeme verteilt werden. Die Folgen eines Ausfalls beschr\u00e4nken sich dadurch in der Regel auf eine moderate Verringerung der Gesamtleistung, ohne dass die Verf\u00fcgbarkeit des Dienstes vollst\u00e4ndig beeintr\u00e4chtigt wird.<\/p>\n\n\n\n

Grunds\u00e4tzlich lassen sich zwei Formen des Load Balancings unterscheiden: statisches und dynamisches Load Balancing. Beim statischen Load Balancing erfolgt die Weiterleitung von Anfragen ausschlie\u00dflich auf Grundlage vordefinierter Regeln, beispielsweise anhand der Reihenfolge der verf\u00fcgbaren Server. Dynamisches Load Balancing ber\u00fccksichtigt hingegen den aktuellen Zustand des Systems und trifft Entscheidungen auf Basis gegenw\u00e4rtiger Metriken, wie etwa der aktuellen Auslastung oder der Antwortzeiten einzelner Server. [11]<\/p>\n\n\n\n

Bei beiden Varianten ist es \u00fcblich, einzelnen Host-Systemen Gewichtungen zuzuweisen. Diese Gewichtungen erm\u00f6glichen eine gezielt ungleichm\u00e4\u00dfige Verteilung der Anfragen, beispielsweise wenn die beteiligten Systeme \u00fcber unterschiedliche Hardwarekapazit\u00e4ten verf\u00fcgen. [11]<\/p>\n\n\n\n

Im Kontext eines Taxidienstes eignet sich insbesondere dynamisches Load Balancing. Dieser Ansatz erm\u00f6glicht eine flexible Verteilung von Anfragen auch dann, wenn die Server eines Shards geographisch verteilt betrieben werden. Der zus\u00e4tzliche Rechenaufwand des komplexeren Verfahrens f\u00fchrt dabei in der Regel nicht zu signifikanten Leistungseinbu\u00dfen. Allerdings muss sichergestellt werden, dass die verwendeten dynamischen Algorithmen tats\u00e4chlich auf aktuelle Systemzust\u00e4nde reagieren und nicht faktisch dasselbe Verhalten wie einfache statische Verfahren aufweisen. Andernfalls k\u00f6nnte beispielsweise ein Algorithmus auf Basis der geringsten Antwortzeit effektiv dieselben Ergebnisse liefern wie ein Round-Robin-Verfahren, wodurch eine ineffiziente Nutzung der Rechenzeit des Load Balancers entstehen w\u00fcrde. [12]<\/p>\n\n\n\n

Uber erweitert das Konzept des Load Balancings zus\u00e4tzlich durch die Technik des Subsetting. Hierbei wird festgelegt,  welchen Teilmengen verf\u00fcgbarer Dienste eingehende Anfragen verteilt werden. Ziel dieses Verfahrens ist die Reduzierung der Anzahl notwendiger Netzwerkverbindungen innerhalb des Dienstnetzes. Bei einer Verteilung s\u00e4mtlicher Anfragen \u00fcber alle verf\u00fcgbaren Instanzen m\u00fcssten zwischen den beteiligten Diensten und Proxys eine sehr gro\u00dfe Anzahl von TCP-Verbindungen aufgebaut und verwaltet werden. Diese Zahl kommt durch die potentiell hohe Anzahl (h\u00e4ufig bis zu mehreren zehntausend) an Microservice-Containern, die auf einem gegebenen Host-Rechner zu einem Zeitpunkt ausgef\u00fchrt wird. Mit einer zunehmenden Anzahl von Services, die entweder durch die Einrichtung neuer Dienste oder durch die horizontale Skalierung bestehender Services entsteht, wird das Problem der Anzahl von TCP-Verbindungen zunehmend signifikant. Ein Subset bezeichnet dabei lediglich eine feste Zahl von Services, die in einer logischen Gruppe zusammengefasst sind und einem Load Balancer zugewiesen werden. [12]<\/p>\n\n\n\n

Netzwerkverbindungen zwischen Diensten werden in der Regel nicht f\u00fcr jede einzelne Anfrage neu aufgebaut und anschlie\u00dfend wieder geschlossen. Stattdessen werden bestehende Verbindungen \u00fcber l\u00e4ngere Zeitr\u00e4ume aufrechterhalten und f\u00fcr mehrere Anfragen wiederverwendet. Dieses Vorgehen reduziert den Kommunikationsaufwand erheblich, da insbesondere bei verbindungsorientierten Protokollen wie TCP der wiederholte Verbindungsaufbau zus\u00e4tzlichen Overhead verursacht. Durch Subsetting kann die Anzahl der dauerhaft aufrechtzuerhaltenden Verbindungen begrenzt werden, wodurch das interne Service-Netzwerk entlastet wird. [12]<\/p>\n\n\n\n

G. Skalierung von Datenbanken<\/h3>\n\n\n\n

Die bisherigen Abschnitte befassten sich ausschlie\u00dflich mit der \u00fcbergeordneten architektonischen Gestaltung eines verteilten Taxidienstes bez\u00fcglich der Anwendung als Gesamteinheit. Neben der Optimierung der Antwortzeit der Anwendung auf Nutzeranfragen stellt die Datenschicht jedoch eine weitere elementare Schicht eines verteilten Dienstes dar, die separat betrachtet werden muss. Durch die Signifikanz und Komplexit\u00e4t der persistenten Datenspeicherung bei verteilten Anwendungen existieren besondere Skalierungstechnicken, die speziell auf Datenspeicherung zugeschnitten sind. Neben der Optimierung der Antwortzeit von Microservices, die vom Endnutzer wahrgenommen wird, m\u00fcssen ebenfalls die Reaktionszeiten der Datenschicht innerhalb der Anwendung optimiert werden, da diese auf \u00e4hnliche Weise anwendungsintern zu Verz\u00f6gerungen bei der Bearbeitung einer Nutzeranfrage f\u00fchren k\u00f6nnen.<\/p>\n\n\n\n

Uber hat eine eigenst\u00e4ndige L\u00f6sung zur Datenpersistierung mit dem Namen Docstore<\/em> entwickelt. Docstore dient als eine allgemeine L\u00f6sung f\u00fcr mehrere datenbezogene Probleme, darunter Replizierung, Partitionierung, und Concurrency beim verteilten Datenbanksystem von Uber. [13]<\/p>\n\n\n\n

\"\"<\/a>
Fig. 3. Grundlegende \u00dcbersicht \u00fcber die Architektur von Docstore und der Partition von Datenbanken. Quelle: https:\/\/www.uber.com\/us\/en\/blog\/from-static-rate-limiting-to-intelligent-load-management (letzter Zugriff: 31. Juli 2026)<\/figcaption><\/figure>\n\n\n\n

Bei Uber werden mehrere Datenbankinstanzen innerhalb von Partitionen zusammengefasst. Dieses Prinzip \u00e4hnelt dem Prinzip des Shardings, welches zuvor beschrieben wurde. Eine M\u00f6glichkeit besteht darin, jede Datenbankinsatnz mit allen Tabellen auszustatten, die in der Datenbankarchitektur der Anwendung existieren, w\u00e4hrend die einzelnen Datens\u00e4tze auf mehrere Partitionen und Datenbankinstanzen verteilt werden.<\/p>\n\n\n\n

Ein h\u00e4ufiges Problem bei verteilten Datenbanken ist die Sicherstellung der Konsistenz. Uber l\u00f6st dieses Problem mit dem Konsensalgorithmus Raft<\/em>. Innerhalb einer Partition wird eine konkrete Datenbankinstanz als die prim\u00e4re Datenquelle designiert und \u00fcbergibt Datenaktualisierungen an die \u00fcbrigen Instanzen innerhalb derselben Partition. Die prim\u00e4re Datenquelle wird im Kontext von Raft als bezeichnet, w\u00e4hrend die \u00fcbrigen Instanzen entsprechend als bezeichnet werden. Dementsprechend finden alle Schreib-Queries zun\u00e4chst auf der Prim\u00e4rdatenbank statt. Im Anschluss wird der neue Datenzustand an die Follower \u00fcbertragen.<\/p>\n\n\n\n

Ein weiteres Problem bei verteilten Datenbanken ist die Durchf\u00fchrung von Join-Operationen zwischen mehreren Tabellen. In der Abfragesprache SQL existiert eine integrierte Syntax, die es erm\u00f6glicht, eine neue Tabelle zu erzeugen, die auf der logischen Schnittmenge zwei verschiedener Tabellen basiert. Bei der r\u00e4umlichen Verteilung logisch zusammenh\u00e4ngender Daten \u00fcber mehrere Instanzen ist eine einfache, lokale SQL-Abfrage nicht mehr ausreichend, um die gew\u00fcnschten Daten vollst\u00e4ndig abzurufen. [14]<\/p>\n\n\n\n

Ebenfalls zu ber\u00fccksichtigen ist die Auffindbarkeit eines bestimmten Datensatzes. Bei der Verteilung von logisch zusammenh\u00e4ngenden Daten \u00fcber mehrere Partitionen und Datenbankinstanzen muss dennoch jederzeit die M\u00f6glichkeit bestehen, alle Daten einer fachlichen Entit\u00e4t, wie beispielsweise eines Nutzers, einer Taxifahrt, oder einer Bestellung, mit m\u00f6glichst wenigen Queries abzufragen. Ein L\u00f6sungsweg besteht darin, das Prinzip der Primary Keys auf Partitionen anzuwenden. In SQL ist es gel\u00e4ufig, einzelnen Datens\u00e4tzen einen Primary Key zuzuordnen, der als ein numerischer Identifikator f\u00fcr einen Datensatz agiert. Dieser Primary Key kann darauffolgend in Datenbankabfragen zur eindeutigen Identifizierung eines Datensatzes verwendet werden. Auf diese Weise wird auf alle Daten zugegriffen, die mit einer bestimmten Entit\u00e4t zusammenh\u00e4ngen. Dieses Prinzip l\u00e4sst sich ebenso auf Datenbankpartitionen \u00fcbertragen, sodass in einer Abfrage nicht nur der Primary Key einer anwendungsbezogenen Entit\u00e4t enthalten ist, sondern auch der Identifikator der Partitionen, in der die gesuchten Daten aufzufinden sind. [14] In diesem Fall bietet es sich an, zus\u00e4tzlich eine Konvention zu etablieren, anhand der die Primary Keys f\u00fcr Partitionen benannt werden, sodass aus jedem Primary key die eindeutige geographische und logische Zone eines Datensatzes auszulesen ist.<\/p>\n\n\n\n

F\u00fcr die richtige Weiterleitung einer Datenbankabfrage an die relevanten Partitionen existiert bei Docstore eine Trennung in eine Query-Schicht und eine Speicherschicht. Die Query-Schicht ist daf\u00fcr zust\u00e4ndig, die Abfragen nach ihrer Plausibilit\u00e4t zu pr\u00fcfen und die Abfrage an die zugeh\u00f6rigen Partitionen weiterzuleiten. Auf der Speicherschicht findet die Partitionierung der Instanzen statt. Ebenfalls ist die Speicherschicht f\u00fcr Konsens und Replizierung verantwortlich. [15] Abbildung 3 veranschaulicht die Aufteilung der Schichten in einer grundlegenden Form.<\/p>\n\n\n\n

H. Adaptive Preisregulierung durch Surge Pricing<\/h3>\n\n\n\n

Ein weiterer Aspekt der Skalierung betrifft die Kostenstruktur eines Systems. Diese beziehen sich nicht ausschlie\u00dflich auf die Infrastrukturkosten, die bereits im Zusammenhang mit Load Balancing und vertikaler CPU-Skalierung ber\u00fccksichtigt wurden, sondern umfassen auch betriebswirtschaftliche Optimierungspotenziale. In diesem Kontext k\u00f6nnen dynamische Preisanpassungen ebenfalls als eine Form der Skalierungsma\u00dfnahme betrachtet werden.<\/p>\n\n\n\n

Im Fall von Uber wird mittels Surge Pricing eine dynamische Anpassung der Fahrpreise in Abh\u00e4ngigkeit von der aktuellen Nachfrage vorgenommen. Dieser Prozess erfolgt algorithmisch. Surge Pricing stellt im Wesentlichen eine Mechanik zur Herstellung eines Gleichgewichts zwischen Angebot und Nachfrage dar, ohne dass eine manuelle Anpassung der Preise in einem dynamischen Umfeld wie dem Taximarkt erforderlich wird. Durch die Automatisierung k\u00f6nnen Preise in kurzen zeitlichen Intervallen, beispielsweise im Minutentakt, an die aktuelle Nachfrage angepasst werden. [16]<\/p>\n\n\n\n

Ohne die Implementierung von Surge Pricing w\u00fcrden dem Unternehmen potenzielle Einnahmen entgehen, die sich aus dem dynamischen Verh\u00e4ltnis von Angebot und Nachfrage auf dem Markt ergeben. Dar\u00fcber hinaus schafft eine dynamische Preisgestaltung Anreize f\u00fcr Fahrdienstpartner, insbesondere in Phasen hoher Nachfrage (hoher Surge-Faktoren) Fahrten anzubieten. In diesen Zeitr\u00e4umen ist das Einkommen der Fahrer erh\u00f6ht, w\u00e4hrend die Nachfrage der Kunden weiterhin ausreichend hoch bleibt, sodass trotz steigender Preise weiterhin eine signifikante Anzahl an Fahrten zustande kommt. [16]<\/p>\n\n\n\n

Die technische Umsetzung von Surge Pricing basiert auf Event-Streaming. Zur Berechnung eines erh\u00f6hten Surge-Faktors wird der vorliegende Event-Stream analysiert, wobei die Dichte der vergangenen Taxibestellungen bestimmt wird. Auf dieser Grundlage wird ein Faktor berechnet, der mit dem Standardpreis multipliziert wird. Die Preisberechnung ist somit direkt von der Historie der erfassten Bestell-Events abh\u00e4ngig. Der Surge-Faktor kann sich bei Uber innerhalb kurzer Zeitr\u00e4ume mehrfach \u00e4ndern, typischerweise etwa alle f\u00fcnf Minuten, wodurch eine robuste Event-Architektur erforderlich ist, die schnelle Reaktionszeiten erm\u00f6glicht.<\/p>\n\n\n\n

Surge Pricing erweitert die Anforderungen an eine eventgetriebene Architektur dahingehend, dass Events nicht ausschlie\u00dflich einmalig an andere Services weitergegeben werden, sondern auch nach ihrer Verarbeitung Auswirkungen auf nachgelagerte Prozesse haben k\u00f6nnen, da s\u00e4mtliche relevanten Ereignisse im System potenziell Einfluss auf zuk\u00fcnftige Preisberechnungen nehmen. [16]<\/p>\n\n\n\n

Dar\u00fcber hinaus verf\u00fcgt Surge Pricing \u00fcber ein eigenes System zur Einteilung von Regionen in logische Einheiten. W\u00e4hrend beim geographischen Sharding diese Einteilung prim\u00e4r der Optimierung der Infrastruktur dient, werden Regionen beim Surge Pricing zur differenzierten Preisgestaltung auf Basis der regionalen Nachfrage verwendet. Im Gegensatz zum geographischen Sharding ist dieser Prozess jedoch komplexer, da die Preiszonen dynamisch von der Nachfrage abh\u00e4ngen, welche innerhalb eines Tages erheblichen Schwankungen unterliegen kann. Das System des geographischen Shardings weist diese dynamische Abh\u00e4ngigkeit nicht auf. Folglich k\u00f6nnen sich die Regionsgrenzen im Surge-Pricing-Kontext mehrfach t\u00e4glich verschieben, was in der Regel den Einsatz automatisierter Verfahren erforderlich macht. [16]<\/p>\n\n\n\n

VI. Fazit<\/h2>\n\n\n\n

Mit den vorgestellten Skalierungstechniken werden verschiedene Ziele verteilter Systeme verfolgt, wobei zugleich unterschiedliche Zielkonflikte und Kompromisse ber\u00fccksichtigt werden m\u00fcssen. Geographisches Sharding gew\u00e4hrleistet einen effizienten Einsatz der verf\u00fcgbaren Hardware, indem jeder Region entsprechend ihres Anfrageaufkommens ausreichende Ressourcen zugewiesen werden. In Kombination mit der dynamischen Anpassung der Hardwarekapazit\u00e4ten pro Shard wird damit das Prinzip der horizontalen Skalierung umgesetzt.<\/p>\n\n\n\n

Zur Gew\u00e4hrleistung einer losen Kopplung sowie einer hohen Austauschbarkeit einzelner Dienste wird eine ereignisgetriebene Architektur eingesetzt. Diese Architektur stellt eine Schnittstelle bereit, \u00fcber die Funktionsaufrufe durch das Ausl\u00f6sen von Ereignissen initiiert werden, sodass Funktionen nicht unmittelbar im Quellcode anderer Dienste aufgerufen werden m\u00fcssen. Dadurch kann das Verhalten einzelner Dienste in hohem Ma\u00dfe angepasst werden, ohne umfangreiche \u00c4nderungen am Quellcode vorzunehmen. Dar\u00fcber hinaus erleichtert dieser Ansatz sowohl den Austausch bestehender Dienste als auch das Hinzuf\u00fcgen oder Entfernen weiterer Komponenten innerhalb der Gesamtarchitektur, da hierf\u00fcr lediglich geringf\u00fcgige Anpassungen an den verkn\u00fcpften Event Listenern erforderlich sind. Mit dieser Technik wird eine Skalierbarkeit im Entwicklungsprozess sichergestellt.<\/p>\n\n\n\n

F\u00fcr die vertikale Skalierung der Hardware eignet sich die dynamische Zuweisung von CPU-Ressourcen. Analog zum geographischen Sharding wird dabei sichergestellt, dass die verf\u00fcgbaren CPU-Kerne m\u00f6glichst effizient genutzt werden, indem jedem Workload nur die tats\u00e4chlich ben\u00f6tigte Rechenkapazit\u00e4t zugewiesen wird. Eine effiziente Nutzung der CPU-Ressourcen tr\u00e4gt zugleich zur Senkung der Betriebskosten bei, da der Energieverbrauch der Infrastruktur reduziert werden kann. Gleichzeitig bleiben jedoch Herausforderungen bestehen, insbesondere die m\u00f6glichst pr\u00e4zise Bestimmung des tats\u00e4chlichen Ressourcenbedarfs eines Workloads sowie die Auswahl geeigneter CPU-Ressourcen unter Ber\u00fccksichtigung unterschiedlicher Hardwarekonfigurationen.<\/p>\n\n\n\n

Neben technischen und infrastrukturellen Fragestellungen muss auch die betriebswirtschaftliche Perspektive eines Taxidienstes ber\u00fccksichtigt werden. W\u00e4hrend durch die Optimierung der Ressourcennutzung Betriebskosten reduziert werden k\u00f6nnen, erm\u00f6glicht eine dynamische Preisgestaltung zus\u00e4tzlich eine Optimierung der Einnahmen. Mithilfe eines Surge-Pricing-Algorithmus k\u00f6nnen Taxipreise mehrmals innerhalb einer Stunde an das aktuelle Verh\u00e4ltnis von Angebot und Nachfrage angepasst werden. An diesem Beispiel wird das Zusammenspiel verschiedener Skalierungstechniken ersichtlich: Die ereignisgetriebene Architektur erm\u00f6glicht die kontinuierliche Protokollierung von Bestellungen und stellt die Grundlage f\u00fcr die Ber\u00fccksichtigung vergangener Ereignisse bei der Neuberechnung der Fahrpreise dar. Gleichzeitig spielt auch die geographische Einteilung eine wesentliche Rolle, da Angebot und Nachfrage regional unterschiedlich ausfallen und sich folglich f\u00fcr jede Region ein eigenes Marktgleichgewicht mit entsprechend unterschiedlichen Fahrpreisen ergibt.<\/p>\n\n\n\n

Die betrachteten Skalierungstechniken verfolgen \u00fcberwiegend das Ziel, die Leistungsf\u00e4higkeit und Ausfallsicherheit verteilter Anwendungen zu erh\u00f6hen sowie Concurrency-Fehler zu vermeiden. Gleichzeitig f\u00fchren sie jedoch zu einer h\u00f6heren Komplexit\u00e4t bei der Entwicklung, dem Betrieb und der Wartung der Anwendung. Insgesamt zeigt sich, dass zahlreiche Skalierungsstrategien auf einer gezielten r\u00e4umlichen oder logischen Aufteilung von Verantwortlichkeiten beruhen, sowohl hinsichtlich der Infrastruktur als auch der Softwarearchitektur. Daraus l\u00e4sst sich schlie\u00dfen, dass die Skalierung verteilter Anwendungen ma\u00dfgeblich auf einer klaren Zuordnung von Rollen, Verantwortlichkeiten und Ressourcen basiert, sodass der Betrieb eines Taxidienstes als verteilte Anwendung unabh\u00e4ngig von der regionalen Ausbreitung und Nachfrage der Angebote jederzeit stabil bleibt.<\/p>\n\n\n\n

\n\n\n\n

Referenzen<\/h2>\n\n\n\n

[1] M. van Steen and A. S. Tanenbaum, Distributed Systems, 4th ed., Jan.
2025.<\/p>\n\n\n\n


[2] Y. Fu and C. Soman, \u201cReal-time Data Infrastructure at Uber,\u201d in
Proceedings of the 2021 International Conference on Management
of Data, Jun. 2021, pp. 2503\u20132516, arXiv:2104.00087 [cs]. [Online].
Available: http:\/\/arxiv.org\/abs\/2104.00087<\/p>\n\n\n\n


[3] J. Clemm, \u201cA Brief History of Scaling Uber,\u201d Jan. 2024. [Online]. Available: https:\/\/www.joshclemm.com\/writing\/a-brief-
history-of-scaling-uber\/<\/p>\n\n\n\n


[4] C. Harris, \u201cMicroservices vs. monolithic architecture | Atlassian.\u201d [On-
line]. Available: https:\/\/www.atlassian.com\/microservices\/microservices-
architecture\/microservices-vs-monolith<\/p>\n\n\n\n


[5] E. Haddad, \u201cService-Oriented Architecture: Scaling the Uber
Engineering Codebase As We Grow,\u201d Sep. 2015. [Online]. Available:
https:\/\/www.uber.com\/de\/en\/blog\/service-oriented-architecture\/<\/p>\n\n\n\n


[6] S. Lee, Z. Guo, O. Sunercan, J. Ying, T. Kooburat, S. Biswal,
J. Chen, K. Huang, Y. Cheung, Y. Zhou, K. Veeraraghavan, B. Damani,
P. M. Ruiz, V. Mehta, and C. Tang, \u201cShard Manager: A Generic
Shard Management Framework for Geo-distributed Applications,\u201d in
Proceedings of the ACM SIGOPS 28th Symposium on Operating
Systems Principles, ser. SOSP \u201921. New York, NY, USA: Association
for Computing Machinery, 2021, pp. 553\u2013569. [Online]. Available:
https:\/\/dl.acm.org\/doi\/10.1145\/3477132.3483546<\/p>\n\n\n\n


[7] S.-M. Peng, R. Dey, and J. He, \u201cCapacity Recommendation Engine:
Throughput and Utilization Based Predictive Scaling.\u201d [Online].
Available: https:\/\/www.uber.com\/de\/en\/blog\/capacity-recommendation-
engine\/<\/p>\n\n\n\n


[8] L. Vilhelmsen, \u201cVertical CPU Scaling: Reduce Cost of
Capacity and Increase Reliability,\u201d Jul. 2022. [Online]. Available:
https:\/\/www.uber.com\/us\/en\/blog\/vertical-cpu-scaling\/<\/p>\n\n\n\n


[9] \u201cWhat is event-driven architecture?\u201d Sep. 2019. [Online].
Available: https:\/\/www.redhat.com\/en\/topics\/integration\/what-is-event-
driven-architecture<\/p>\n\n\n\n


[10] J. Ferrer, \u201cKafka vs RabbitMQ: Key Differences & When to Use Each,\u201d
Feb. 2025. [Online]. Available: https:\/\/www.datacamp.com\/blog\/kafka-
vs-rabbitmq<\/p>\n\n\n\n


[11] \u201cTypes of load balancing algorithms.\u201d [Online]. Avail-
able: https:\/\/www.cloudflare.com\/learning\/performance\/types-of-load-
balancing-algorithms\/<\/p>\n\n\n\n


[12] C.-C. Liao, S. Kundu, and P. Krolikowski, \u201cBetter Load
Balancing: Real-Time Dynamic Subsetting.\u201d [Online]. Avail-
able: https:\/\/www.uber.com\/de\/en\/blog\/better-load-balancing-real-time-
dynamic-subsetting\/<\/p>\n\n\n\n


[13] H. Chaudhary, O. Tariq, and D. Chatterjee, \u201cEvolving Schemaless
into a Distributed SQL Database,\u201d Feb. 2021. [Online]. Available:
https:\/\/www.uber.com\/us\/en\/blog\/schemaless-sql-database\/<\/p>\n\n\n\n


[14] A. Ahmad, \u201cScaling SQL Databases: 8 Challenges of
Horizontally Scaling SQL Databases.\u201d [Online]. Available:
https:\/\/www.designgurus.io\/blog\/scaling-sql-databases<\/p>\n\n\n\n


[15] D. Vaidya, P. Deshpande, and M. Ma, \u201cHow Uber
Conquered Database Overload: The Journey from Static Rate-
Limiting to Intelligent Load Management,\u201d Apr. 2026. [Online].
Available: https:\/\/www.uber.com\/us\/en\/blog\/from-static-rate-limiting-to-
intelligent-load-management\/<\/p>\n\n\n\n


[16] L. Chen, A. Mislove, and C. Wilson, \u201cPeeking Beneath the
Hood of Uber,\u201d in Proceedings of the 2015 Internet Measurement
Conference, ser. IMC \u201915. New York, NY, USA: Association
for Computing Machinery, 2015, pp. 495\u2013508. [Online]. Available:
https:\/\/dl.acm.org\/doi\/10.1145\/2815675.2815681<\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

Abstract: Skalierbarkeit geh\u00f6rt zu den zentralen Themen verteilter Systeme. Mit zunehmender Nachfrage und regionaler Ausbreitung eines verteilten Dienstes sind im Lauf der Zeit erhebliche Einschr\u00e4nkungen in der Leistung und Zuverl\u00e4ssigkeit zu erwarten. Insbesondere bei einem Taxidienst, dessen Dienste weltweit \u00fcber eine mobile Anwendung angeboten werden, m\u00fcssen spezifische technische Gegebenheiten wie Echtzeit\u00fcbertragung und die H\u00e4ufigkeit von […]<\/p>\n","protected":false},"author":1330,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[650,223],"tags":[7,91,1251,448,415],"ppma_author":[1250],"class_list":["post-29104","post","type-post","status-publish","format-standard","hentry","category-scalable-systems","category-ultra-large-scale-systems","tag-cloud","tag-microservices","tag-partitioning","tag-scalability","tag-sharding"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t