Web Analytics

system-design-primer

⭐ 318813 stars German by donnemartin

English ∙ 日本語 ∙ 简体中文 ∙ 繁體中文 | العَرَبِيَّة‎ ∙ বাংলা ∙ Português do Brasil ∙ Deutsch ∙ ελληνικά ∙ עברית ∙ Italiano ∙ 한국어 ∙ فارسی ∙ Polski ∙ русский язык ∙ Español ∙ ภาษาไทย ∙ Türkçe ∙ tiếng Việt ∙ Français | Add Translation

Hilf mit, diesen Leitfaden zu übersetzen!

Das System Design Primer


Motivation

Lerne, wie man groß angelegte Systeme entwirft.
>
Vorbereitung auf das Systemdesign-Interview.

Lerne, wie man groß angelegte Systeme entwirft

Das Erlernen der Skalierung von Systemen hilft dir, ein besserer Ingenieur zu werden.

Systemdesign ist ein breit gefächertes Thema. Es gibt eine riesige Menge an Ressourcen, die im Web verstreut sind zu Prinzipien des Systemdesigns.

Dieses Repository ist eine organisierte Sammlung von Ressourcen, die dir helfen, Systeme im großen Maßstab zu bauen.

Lerne von der Open-Source-Community

Dies ist ein fortlaufend aktualisiertes Open-Source-Projekt.

Beiträge sind willkommen!

Vorbereitung auf das Systemdesign-Interview

Neben Coding-Interviews ist Systemdesign ein notwendiger Bestandteil des technischen Bewerbungsprozesses bei vielen Tech-Unternehmen.

Übe gängige Systemdesign-Interviewfragen und vergleiche deine Ergebnisse mit Beispiellösungen: Diskussionen, Code und Diagramme.

Zusätzliche Themen zur Interviewvorbereitung:

Anki-Lernkarten


Die bereitgestellten Anki-Lernkartendecks nutzen verteiltes Wiederholen, um Ihnen beim Behalten wichtiger Systemdesign-Konzepte zu helfen.

Ideal für unterwegs.

Coding Resource: Interaktive Programmieraufgaben

Suchen Sie nach Ressourcen, um sich auf das Coding-Interview vorzubereiten?


Werfen Sie einen Blick auf das Schwester-Repository Interactive Coding Challenges, das ein weiteres Anki-Deck enthält:

Mitwirken

Lernen Sie von der Community.

Sie können gerne Pull-Requests einreichen, um zu helfen:

Inhalt, der noch überarbeitet werden muss, befindet sich in Entwicklung.

Siehe die Mitwirkungsrichtlinien.

Index der Themen zum Systemdesign

Zusammenfassungen verschiedener Systemdesign-Themen, einschließlich Vor- und Nachteilen. Alles ist ein Kompromiss.
>
Jeder Abschnitt enthält Links zu weiterführenden Ressourcen.


Lernleitfaden

Vorgeschlagene Themen zur Wiederholung, basierend auf deinem Interview-Zeitplan (kurz, mittel, lang).

Imgur

F: Muss ich für Interviews alles hier wissen?

A: Nein, du musst nicht alles hier wissen, um dich auf das Interview vorzubereiten.

Was in einem Interview gefragt wird, hängt von Faktoren wie folgenden ab:

Von erfahrenen Kandidaten wird im Allgemeinen mehr Wissen über Systemdesign erwartet. Architekten oder Teamleiter sollten mehr wissen als einzelne Entwickler. Bei führenden Tech-Unternehmen gibt es wahrscheinlich eine oder mehrere Design-Interviewrunden.

Beginnen Sie mit einem breiten Überblick und vertiefen Sie sich in einige Bereiche. Es hilft, ein wenig über verschiedene wichtige Themen im Bereich Systemdesign zu wissen. Passen Sie den folgenden Leitfaden an Ihren Zeitplan, Ihre Erfahrung, die Positionen, für die Sie sich bewerben, und die Unternehmen, bei denen Sie sich bewerben, an.

| | Kurz | Mittel | Lang | |---|---|---|---| | Lesen Sie die Systemdesign-Themen, um ein breites Verständnis davon zu bekommen, wie Systeme funktionieren | :+1: | :+1: | :+1: | | Lesen Sie einige Artikel in den Engineering-Blogs der Unternehmen, bei denen Sie sich bewerben | :+1: | :+1: | :+1: | | Lesen Sie einige Architekturen aus der Praxis | :+1: | :+1: | :+1: | | Überprüfen Sie Wie man eine Systemdesign-Interviewfrage angeht | :+1: | :+1: | :+1: | | Bearbeiten Sie Systemdesign-Interviewfragen mit Lösungen | Einige | Viele | Die meisten | | Bearbeiten Sie Objektorientierte Design-Interviewfragen mit Lösungen | Einige | Viele | Die meisten | | Überprüfen Sie Weitere Systemdesign-Interviewfragen | Einige | Viele | Die meisten |

Wie man eine Systemdesign-Interviewfrage angeht

Wie man eine Systemdesign-Interviewfrage angeht.

Das Systemdesign-Interview ist ein offenes Gespräch. Sie sollen es führen.

Sie können die folgenden Schritte nutzen, um die Diskussion zu leiten. Um diesen Prozess zu festigen, arbeiten Sie den Abschnitt Systemdesign-Interviewfragen mit Lösungen anhand der folgenden Schritte durch.

Schritt 1: Anwendungsfälle, Einschränkungen und Annahmen umreißen

Ermitteln Sie Anforderungen und stecken Sie das Problem ab. Stellen Sie Fragen, um Anwendungsfälle und Einschränkungen zu klären. Diskutieren Sie Annahmen.

Schritt 2: Entwerfen Sie ein High-Level-Design

Umreißen Sie ein High-Level-Design mit allen wichtigen Komponenten.

Schritt 3: Entwerfen Sie die Kernkomponenten

Gehen Sie ins Detail für jede Kernkomponente. Wenn Sie beispielsweise gebeten würden, einen URL-Verkürzungsdienst zu entwerfen, besprechen Sie:

Schritt 4: Skalieren Sie das Design

Identifizieren und adressieren Sie Engpässe unter den gegebenen Einschränkungen. Benötigen Sie beispielsweise Folgendes, um Skalierbarkeitsprobleme zu lösen?

Diskutieren Sie mögliche Lösungen und Kompromisse. Alles ist ein Kompromiss. Gehen Sie auf Engpässe ein und nutzen Sie die Prinzipien des skalierbaren Systemdesigns.

Überschlagsrechnungen

Es kann sein, dass Sie einige Schätzungen von Hand durchführen sollen. Siehe Anhang für die folgenden Ressourcen:

Quelle(n) und weiterführende Literatur

Schauen Sie sich die folgenden Links an, um einen besseren Eindruck davon zu bekommen, was Sie erwartet:

Systemdesign-Interviewfragen mit Lösungen

Häufige Systemdesign-Interviewfragen mit Beispiel-Diskussionen, Code und Diagrammen.
>
Lösungen sind mit Inhalten im Ordner solutions/ verlinkt.

| Frage | | |---|---| | Entwerfen Sie Pastebin.com (oder Bit.ly) | Lösung | | Entwerfen Sie die Twitter-Timeline und Suche (oder Facebook-Feed und Suche) | Lösung | | Entwerfen Sie einen Webcrawler | Lösung | | Entwerfen Sie Mint.com | Lösung | | Entwerfen Sie die Datenstrukturen für ein soziales Netzwerk | Lösung | | Entwerfen Sie einen Key-Value-Store für eine Suchmaschine | Lösung | | Entwerfen Sie die Verkaufsrangliste nach Kategorie von Amazon | Lösung | | Entwerfen Sie ein System, das auf AWS für Millionen von Nutzern skaliert | Lösung | | Fügen Sie eine Systemdesign-Frage hinzu | Beitragen |

Pastebin.com (oder Bit.ly) entwerfen

Übung und Lösung ansehen

Imgur

Die Twitter-Timeline und Suche entwerfen (oder Facebook-Feed und Suche)

Übung und Lösung ansehen

Imgur

Einen Webcrawler entwerfen

Übung und Lösung ansehen

Imgur

Design Mint.com

View exercise and solution

Imgur

Design the data structures for a social network

View exercise and solution

Imgur

Design a key-value store for a search engine

View exercise and solution

Imgur

Design Amazon's sales ranking by category feature

View exercise and solution

Imgur

Design a system that scales to millions of users on AWS

View exercise and solution

Imgur

Object-oriented design interview questions with solutions

Common object-oriented design interview questions with sample discussions, code, and diagrams.
>
Solutions linked to content in the solutions/ folder.

>Note: This section is under development

| Question | | |---|---| | Entwerfen Sie eine Hash Map | Lösung | | Entwerfen Sie einen Least Recently Used Cache | Lösung | | Entwerfen Sie ein Callcenter | Lösung | | Entwerfen Sie ein Kartenspiel-Deck | Lösung | | Entwerfen Sie einen Parkplatz | Lösung | | Entwerfen Sie einen Chat-Server | Lösung | | Entwerfen Sie ein zirkuläres Array | Mitwirken | | Fügen Sie eine objektorientierte Designfrage hinzu | Mitwirken |

Themen zur Systemarchitektur: Starten Sie hier

Neu im Bereich Systemarchitektur?

Zuerst benötigen Sie ein grundlegendes Verständnis für gängige Prinzipien, erfahren, was sie sind, wie sie verwendet werden und ihre Vor- und Nachteile.

Schritt 1: Sehen Sie sich die Skalierbarkeits-Vorlesung an

Skalierbarkeits-Vorlesung an der Harvard

Schritt 2: Lesen Sie den Skalierbarkeits-Artikel

Skalierbarkeit

Nächste Schritte

Als nächstes betrachten wir hochrangige Abwägungen:

Beachte, dass alles eine Abwägung ist.

Anschließend tauchen wir in spezifischere Themen wie DNS, CDNs und Load Balancer ein.

Leistung vs Skalierbarkeit

Ein Dienst ist skalierbar, wenn er eine gesteigerte Leistung proportional zu hinzugefügten Ressourcen zeigt. Im Allgemeinen bedeutet eine Leistungssteigerung, mehr Arbeitseinheiten zu bedienen, aber es kann auch bedeuten, größere Arbeitseinheiten zu bewältigen, etwa wenn Datensätze wachsen.1

Eine weitere Sichtweise auf Leistung vs Skalierbarkeit:

Quelle(n) und weiterführende Literatur

Latenz vs Durchsatz

Latenz ist die Zeit, um eine Aktion auszuführen oder ein Ergebnis zu erzeugen.

Durchsatz ist die Anzahl solcher Aktionen oder Ergebnisse pro Zeiteinheit.

Im Allgemeinen solltest du auf maximalen Durchsatz mit akzeptabler Latenz abzielen.

Quelle(n) und weiterführende Literatur

Verfügbarkeit vs Konsistenz

CAP-Theorem


Quelle: CAP-Theorem erneut betrachtet

In einem verteilten Computersystem können Sie nur zwei der folgenden Garantien unterstützen:

Netzwerke sind nicht zuverlässig, daher müssen Sie Partitionstoleranz unterstützen. Sie müssen einen Software-Kompromiss zwischen Konsistenz und Verfügbarkeit eingehen.

#### CP – Konsistenz und Partitionstoleranz

Das Warten auf eine Antwort vom partitionierten Knoten kann zu einem Timeout-Fehler führen. CP ist eine gute Wahl, wenn Ihr Geschäftsbedarf atomare Lese- und Schreibvorgänge erfordert.

#### AP – Verfügbarkeit und Partitionstoleranz

Antworten liefern die am einfachsten verfügbare Version der Daten auf einem beliebigen Knoten, die möglicherweise nicht die aktuellste ist. Schreibvorgänge können etwas Zeit benötigen, um sich nach Behebung der Partition zu verbreiten.

AP ist eine gute Wahl, wenn die Geschäftsanforderungen eventuelle Konsistenz erlauben oder das System trotz externer Fehler weiterarbeiten muss.

Quelle(n) und weiterführende Literatur

Konsistenzmuster

Bei mehreren Kopien derselben Daten stehen wir vor der Frage, wie wir diese synchronisieren, sodass Clients eine konsistente Sicht auf die Daten erhalten. Erinnern Sie sich an die Definition von Konsistenz aus dem CAP-Theorem – Jeder Lesevorgang erhält entweder den aktuellsten Schreibvorgang oder einen Fehler.

Schwache Konsistenz

Nach einem Schreibvorgang kann ein Lesevorgang diesen sehen oder auch nicht. Es wird ein Best-Effort-Ansatz verfolgt.

Dieser Ansatz findet sich in Systemen wie memcached. Schwache Konsistenz funktioniert gut in Echtzeit-Anwendungen wie VoIP, Videochat und Echtzeit-Mehrspieler-Spielen. Wenn Sie beispielsweise während eines Telefonats für einige Sekunden den Empfang verlieren, hören Sie nach Wiederherstellung der Verbindung nicht, was während des Verbindungsverlusts gesprochen wurde.

Eventual Consistency (Schlussendliche Konsistenz)

Nach einem Schreibvorgang werden Leseoperationen diesen Wert schließlich sehen (typischerweise innerhalb von Millisekunden). Daten werden asynchron repliziert.

Dieser Ansatz findet sich in Systemen wie DNS und E-Mail. Schlussendliche Konsistenz funktioniert gut in hochverfügbaren Systemen.

Starke Konsistenz

Nach einem Schreibvorgang werden Leseoperationen diesen Wert sehen. Daten werden synchron repliziert.

Dieser Ansatz findet sich in Dateisystemen und RDBMS. Starke Konsistenz eignet sich gut für Systeme, die Transaktionen benötigen.

Quelle(n) und weiterführende Literatur

Verfügbarkeitsmuster

Es gibt zwei ergänzende Muster zur Unterstützung hoher Verfügbarkeit: Failover und Replikation.

Failover

#### Aktiv-Passiv

Beim Aktiv-Passiv-Failover werden Heartbeats zwischen dem aktiven und dem passiven Server im Standby-Modus gesendet. Wenn der Heartbeat unterbrochen wird, übernimmt der passive Server die IP-Adresse des aktiven Servers und setzt den Dienst fort.

Die Ausfallzeit hängt davon ab, ob der passive Server bereits im 'heißen' Standby läuft oder erst aus dem 'kalten' Standby hochgefahren werden muss. Nur der aktive Server verarbeitet den Datenverkehr.

Aktiv-Passiv-Failover wird auch als Master-Slave-Failover bezeichnet.

#### Aktiv-Aktiv

Beim Aktiv-Aktiv-Failover verwalten beide Server den Datenverkehr und verteilen die Last zwischen sich.

Wenn die Server öffentlich zugänglich sind, muss das DNS über die öffentlichen IPs beider Server Bescheid wissen. Wenn die Server intern genutzt werden, muss die Anwendungslogik beide Server kennen.

Aktiv-Aktiv-Failover wird auch als Master-Master-Failover bezeichnet.

Nachteil(e): Failover

Replikation

#### Master-Slave und Master-Master

Dieses Thema wird im Abschnitt Datenbank weiter behandelt:

Verfügbarkeit in Zahlen

Verfügbarkeit wird häufig anhand der Betriebszeit (oder Ausfallzeit) als Prozentsatz der Zeit gemessen, in der der Dienst verfügbar ist. Die Verfügbarkeit wird allgemein in Anzahl der Neunen angegeben–ein Dienst mit 99,99 % Verfügbarkeit wird als vier Neunen beschrieben.

#### 99,9 % Verfügbarkeit - drei Neunen

| Zeitraum | Zulässige Ausfallzeit| |---------------------|----------------------| | Ausfallzeit pro Jahr| 8h 45min 57s | | Ausfallzeit pro Monat| 43m 49,7s | | Ausfallzeit pro Woche| 10m 4,8s | | Ausfallzeit pro Tag | 1m 26,4s |

#### 99,99 % Verfügbarkeit - vier Neunen

| Zeitraum | Zulässige Ausfallzeit| |---------------------|----------------------| | Ausfallzeit pro Jahr| 52min 35,7s | | Ausfallzeit pro Monat| 4m 23s | | Ausfallzeit pro Woche| 1m 5s | | Ausfallzeit pro Tag | 8,6s |

#### Verfügbarkeit in Parallel- vs. Reihenfolge

Wenn ein Dienst aus mehreren ausfallgefährdeten Komponenten besteht, hängt die Gesamtverfügbarkeit des Dienstes davon ab, ob die Komponenten in Reihenfolge oder parallel angeordnet sind.

###### In Reihenfolge Die Gesamtverfügbarkeit sinkt, wenn zwei Komponenten mit einer Verfügbarkeit von < 100% in Reihe geschaltet sind:

Availability (Total) = Availability (Foo) * Availability (Bar)

Wenn sowohl Foo als auch Bar jeweils eine Verfügbarkeit von 99,9 % hätten, läge ihre Gesamtverfügbarkeit in Reihe bei 99,8 %.

###### Parallel

Die Gesamtverfügbarkeit steigt, wenn zwei Komponenten mit einer Verfügbarkeit < 100 % parallel geschaltet sind:

Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))
Wenn sowohl Foo als auch Bar jeweils 99,9 % Verfügbarkeit hätten, läge ihre Gesamtverfügbarkeit im Parallelbetrieb bei 99,9999 %.

Domain Name System


Quelle: DNS Security Presentation

Ein Domain Name System (DNS) übersetzt einen Domainnamen wie www.example.com in eine IP-Adresse.

DNS ist hierarchisch aufgebaut, mit wenigen autoritativen Servern auf der obersten Ebene. Ihr Router oder ISP gibt an, welchen DNS-Server (bzw. welche Server) Sie bei einer Abfrage kontaktieren sollen. DNS-Server auf niedrigeren Ebenen speichern Zuordnungen im Cache, die durch DNS-Propagation veralten können. Auch Ihr Browser oder Betriebssystem kann DNS-Ergebnisse für eine bestimmte Zeitspanne cachen, die durch die Time to Live (TTL) bestimmt wird.

Dienste wie CloudFlare und Route 53 bieten verwaltete DNS-Dienste an. Manche DNS-Dienste können den Datenverkehr auf verschiedene Arten routen:

Nachteil(e): DNS

Quelle(n) und weiterführende Literatur

Content-Delivery-Netzwerk


Quelle: Warum ein CDN nutzen

Ein Content-Delivery-Netzwerk (CDN) ist ein weltweit verteiltes Netzwerk von Proxy-Servern, das Inhalte von Standorten in der Nähe des Nutzers bereitstellt. Im Allgemeinen werden statische Dateien wie HTML/CSS/JS, Fotos und Videos von CDNs bereitgestellt, obwohl einige CDNs wie Amazons CloudFront auch dynamische Inhalte unterstützen. Die DNS-Auflösung der Website teilt den Clients mit, welchen Server sie kontaktieren sollen.

Die Bereitstellung von Inhalten über CDNs kann die Performance auf zwei Arten erheblich verbessern:

Push-CDNs

Push-CDNs erhalten neue Inhalte, sobald Änderungen auf Ihrem Server erfolgen. Sie sind vollständig verantwortlich für die Bereitstellung der Inhalte, laden sie direkt auf das CDN hoch und passen die URLs an, sodass sie auf das CDN verweisen. Sie können konfigurieren, wann Inhalte ablaufen und aktualisiert werden. Inhalte werden nur hochgeladen, wenn sie neu oder geändert sind, was den Traffic minimiert, aber den Speicherbedarf maximiert.

Webseiten mit wenig Traffic oder Webseiten mit Inhalten, die selten aktualisiert werden, funktionieren gut mit Push-CDNs. Inhalte werden einmalig auf das CDN geladen, statt regelmäßig neu abgerufen zu werden.

Pull-CDNs

Pull-CDNs laden neue Inhalte von Ihrem Server, wenn der erste Nutzer die Inhalte anfordert. Sie lassen die Inhalte auf Ihrem Server und passen die URLs an, sodass sie auf das CDN verweisen. Dies führt zu einer langsameren Anfrage, bis die Inhalte im CDN zwischengespeichert sind.

Ein Time-to-Live (TTL) bestimmt, wie lange Inhalte zwischengespeichert werden. Pull-CDNs minimieren den Speicherbedarf im CDN, können aber zu redundantem Traffic führen, wenn Dateien ablaufen und abgerufen werden, bevor sie tatsächlich geändert wurden.

Webseiten mit viel Traffic funktionieren gut mit Pull-CDNs, da der Traffic gleichmäßiger verteilt wird und nur kürzlich angeforderte Inhalte auf dem CDN verbleiben.

Nachteil(e): CDN

Quelle(n) und weiterführende Literatur

Load Balancer


Quelle: Skalierbare Systemdesignmuster

Load Balancer verteilen eingehende Client-Anfragen an Computerressourcen wie Anwendungsserver und Datenbanken. In jedem Fall gibt der Load Balancer die Antwort der Computerressource an den entsprechenden Client zurück. Load Balancer sind effektiv bei:

Load Balancer können mit Hardware (teuer) oder mit Software wie HAProxy implementiert werden.

Zusätzliche Vorteile sind:

Um sich vor Ausfällen zu schützen, ist es üblich, mehrere Load Balancer einzurichten, entweder im Active-Passive- oder Active-Active-Modus.

Load Balancer können den Datenverkehr anhand verschiedener Metriken routen, darunter:

Layer-4-Load-Balancing

Layer-4-Load-Balancer betrachten Informationen auf der Transportschicht, um zu entscheiden, wie Anfragen verteilt werden. Im Allgemeinen betrifft dies die Quell- und Ziel-IP-Adressen und Ports im Header, jedoch nicht den Inhalt des Pakets. Layer-4-Load-Balancer leiten Netzwerkpakete zum und vom Upstream-Server weiter und führen Network Address Translation (NAT) durch.

Layer-7-Load-Balancing

Layer-7-Load-Balancer betrachten die Application Layer, um zu entscheiden, wie Anfragen verteilt werden. Dies kann Inhalte des Headers, der Nachricht und Cookies beinhalten. Layer-7-Load-Balancer beenden den Netzwerkverkehr, lesen die Nachricht, treffen eine Load-Balancing-Entscheidung und öffnen dann eine Verbindung zum ausgewählten Server. Ein Layer-7-Load-Balancer kann beispielsweise Videodatenverkehr zu Servern leiten, die Videos hosten, während sensibler Benutzer-Abrechnungsverkehr zu sicherheitsgehärteten Servern geleitet wird.

Auf Kosten der Flexibilität erfordert Layer-4-Load-Balancing weniger Zeit und Rechenressourcen als Layer-7, obwohl der Performance-Einfluss auf moderner Standardhardware minimal sein kann.

Horizontales Skalieren

Load-Balancer können auch beim horizontalen Skalieren helfen und so Leistung und Verfügbarkeit verbessern. Das Skalieren mit Standardmaschinen ist kostengünstiger und führt zu höherer Verfügbarkeit als das Aufrüsten eines einzelnen Servers auf teurerer Hardware, was als vertikales Skalieren bezeichnet wird. Es ist außerdem einfacher, Fachkräfte für Standardhardware zu finden als für spezialisierte Enterprise-Systeme.

#### Nachteil(e): horizontales Skalieren

Nachteil(e): Load-Balancer

Quelle(n) und weiterführende Literatur

Reverse Proxy (Webserver)


Quelle: Wikipedia

Ein Reverse Proxy ist ein Webserver, der interne Dienste zentralisiert und öffentliche Schnittstellen bereitstellt. Anfragen von Clients werden an einen Server weitergeleitet, der sie erfüllen kann, bevor der Reverse Proxy die Antwort des Servers an den Client zurückgibt.

Weitere Vorteile sind:

Load Balancer vs Reverse Proxy

Nachteil(e): Reverse Proxy

Quelle(n) und weiterführende Literatur

Anwendungsschicht


Quelle: Einführung in die Systemarchitektur für Skalierung

Die Trennung der Webschicht von der Anwendungsschicht (auch als Plattformschicht bekannt) ermöglicht es, beide Schichten unabhängig voneinander zu skalieren und zu konfigurieren. Das Hinzufügen einer neuen API führt zum Hinzufügen von Anwendungsservern, ohne dass zwangsläufig zusätzliche Webserver benötigt werden. Das Single-Responsibility-Prinzip befürwortet kleine und autonome Dienste, die zusammenarbeiten. Kleine Teams mit kleinen Diensten können aggressiver für schnelles Wachstum planen.

Worker in der Anwendungsschicht ermöglichen außerdem Asynchronität.

Microservices

Verwandt mit dieser Diskussion sind Microservices, die als eine Suite von unabhängig bereitstellbaren, kleinen, modularen Diensten beschrieben werden können. Jeder Dienst läuft in einem eigenen Prozess und kommuniziert über einen klar definierten, leichtgewichtigen Mechanismus, um ein Geschäftsziel zu erfüllen. 1

Pinterest könnte beispielsweise folgende Microservices haben: Nutzerprofil, Follower, Feed, Suche, Foto-Upload usw.

Service Discovery

Systeme wie Consul, Etcd, und Zookeeper helfen Diensten, sich gegenseitig zu finden, indem sie registrierte Namen, Adressen und Ports verfolgen. Health Checks helfen, die Integrität der Dienste zu überprüfen und werden oft über einen HTTP-Endpunkt durchgeführt. Sowohl Consul als auch Etcd verfügen über einen eingebauten Key-Value Store, der sich zum Speichern von Konfigurationswerten und anderen gemeinsamen Daten eignet.

Nachteil(e): Anwendungsschicht

Quelle(n) und weiterführende Literatur

Datenbank


Quelle: Skalierung auf die ersten 10 Millionen Nutzer

Relationale Datenbankmanagementsysteme (RDBMS)

Eine relationale Datenbank wie SQL ist eine Sammlung von Datenelementen, die in Tabellen organisiert sind.

ACID ist eine Eigenschaftengruppe von relationalen Datenbank-Transaktionen).

Es gibt viele Techniken, um eine relationale Datenbank zu skalieren: Master-Slave-Replikation, Master-Master-Replikation, Föderation, Sharding, Denormalisierung und SQL-Tuning.

#### Master-Slave-Replikation

Der Master verarbeitet Lese- und Schreibzugriffe und repliziert Schreibzugriffe an einen oder mehrere Slaves, die ausschließlich Lesezugriffe bedienen. Slaves können auch an weitere Slaves in einer baumartigen Struktur replizieren. Wenn der Master ausfällt, kann das System im Nur-Lese-Modus weiterarbeiten, bis ein Slave zum Master befördert oder ein neuer Master bereitgestellt wird.


Quelle: Skalierbarkeit, Verfügbarkeit, Stabilität, Muster

##### Nachteil(e): Master-Slave-Replikation

#### Master-Master-Replikation

Beide Master bedienen Lese- und Schreibzugriffe und koordinieren Schreibzugriffe miteinander. Fällt einer der Master aus, kann das System weiterhin mit Lese- und Schreibzugriffen arbeiten.


Quelle: Skalierbarkeit, Verfügbarkeit, Stabilität, Muster

##### Nachteil(e): Master-Master-Replikation

##### Nachteil(e): Replikation

##### Quelle(n) und weiterführende Literatur: Replikation

#### Föderation


Quelle: Scaling up to your first 10 million users

Föderation (oder funktionale Partitionierung) teilt Datenbanken nach Funktion auf. Zum Beispiel könnte man statt einer einzigen, monolithischen Datenbank drei Datenbanken haben: foren, benutzer und produkte, was zu weniger Lese- und Schreibverkehr pro Datenbank und somit zu geringerer Replikationsverzögerung führt. Kleinere Datenbanken erlauben mehr Daten im Arbeitsspeicher, was wiederum zu mehr Cache-Treffern durch verbesserte Cache-Lokalität führt. Da kein zentraler Master die Schreibvorgänge serialisiert, kann parallel geschrieben werden, was den Durchsatz erhöht.

##### Nachteil(e): Föderation

##### Quelle(n) und weiterführende Literatur: Föderation

#### Sharding


Quelle: Skalierbarkeit, Verfügbarkeit, Stabilitätsmuster

Sharding verteilt Daten auf verschiedene Datenbanken, so dass jede Datenbank nur einen Teil der Daten verwalten kann. Am Beispiel einer Benutzerdatenbank: Mit steigender Anzahl der Benutzer werden dem Cluster weitere Shards hinzugefügt.

Ähnlich wie die Vorteile von Federation führt Sharding zu weniger Lese- und Schreibverkehr, weniger Replikation und mehr Cache-Treffern. Auch die Indexgröße wird reduziert, was die Performance mit schnelleren Abfragen meist verbessert. Fällt ein Shard aus, sind die anderen weiterhin funktionsfähig, obwohl man zur Vermeidung von Datenverlust eine Replikation hinzufügen sollte. Wie bei Federation gibt es keinen zentralen Master, der Schreibvorgänge serialisiert, sodass paralleles Schreiben mit höherem Durchsatz möglich ist.

Übliche Methoden zum Sharding einer Benutzertabelle sind entweder über das Anfangsbuchstaben des Nachnamens oder den geografischen Standort des Benutzers.

##### Nachteil(e): Sharding

##### Quelle(n) und weiterführende Literatur: Sharding

#### Denormalisierung

Denormalisierung versucht, die Leseleistung auf Kosten der Schreibperformance zu verbessern. Redundante Kopien der Daten werden in mehreren Tabellen gespeichert, um teure Joins zu vermeiden. Einige relationale DBMS wie PostgreSQL und Oracle unterstützen materialisierte Sichten, die das Speichern redundanter Informationen und deren Konsistenz automatisch übernehmen.

Sobald Daten mit Techniken wie Federation und Sharding verteilt werden, erhöht das Management von Joins über Rechenzentren hinweg die Komplexität weiter. Denormalisierung kann die Notwendigkeit solcher komplexen Joins umgehen.

In den meisten Systemen stehen die Lesezugriffe den Schreibzugriffen im Verhältnis 100:1 oder sogar 1000:1 gegenüber. Ein Lesezugriff, der einen komplexen Datenbank-Join erfordert, kann sehr teuer sein und viel Zeit für Plattenoperationen beanspruchen.

##### Nachteil(e): Denormalisierung

###### Quelle(n) und weiterführende Literatur: Denormalisierung

#### SQL-Tuning

SQL-Tuning ist ein umfangreiches Thema und viele Bücher wurden als Referenz geschrieben.

Es ist wichtig, Benchmarks und Profiling durchzuführen, um Engpässe zu simulieren und aufzudecken.

Benchmarking und Profiling können auf folgende Optimierungen hinweisen.

##### Das Schema optimieren

##### Gute Indizes verwenden

##### Aufwändige Joins vermeiden

##### Tabellen partitionieren

##### Optimieren Sie den Abfrage-Cache

##### Quelle(n) und weitere Lektüre: SQL-Tuning

NoSQL

NoSQL ist eine Sammlung von Datenelementen, die als Key-Value Store, Dokumenten-Store, Wide Column Store oder Graphdatenbank dargestellt werden. Die Daten sind denormalisiert, und Joins werden in der Regel im Anwendungscode durchgeführt. Die meisten NoSQL-Stores verfügen nicht über echte ACID-Transaktionen und bevorzugen eventuelle Konsistenz.

BASE wird oft verwendet, um die Eigenschaften von NoSQL-Datenbanken zu beschreiben. Im Vergleich zum CAP-Theorem wählt BASE Verfügbarkeit statt Konsistenz.

Zusätzlich zur Entscheidung zwischen SQL oder NoSQL ist es hilfreich zu verstehen, welcher Typ von NoSQL-Datenbank am besten zu Ihrem Anwendungsfall passt. Im nächsten Abschnitt werden wir Key-Value Stores, Dokumenten-Stores, Wide Column Stores und Graphdatenbanken betrachten.

#### Key-Value Store

Abstraktion: Hashtabelle

Ein Key-Value Store erlaubt im Allgemeinen O(1)-Lese- und Schreibzugriffe und basiert oft auf Speicher oder SSD. Datenspeicher können Schlüssel in lexikographischer Reihenfolge halten, was eine effiziente Abfrage von Schlüsselbereichen ermöglicht. Key-Value Stores erlauben das Speichern von Metadaten zusammen mit einem Wert.

Key-Value Stores bieten hohe Leistung und werden häufig für einfache Datenmodelle oder für sich schnell ändernde Daten wie z.B. eine In-Memory-Cache-Schicht verwendet. Da sie nur einen begrenzten Satz von Operationen bieten, wird zusätzliche Komplexität bei Bedarf auf die Anwendungsebene verlagert.

Ein Key-Value Store bildet die Grundlage für komplexere Systeme wie z.B. einen Dokumenten-Store und in manchen Fällen auch für eine Graphdatenbank.

##### Quelle(n) und weitere Lektüre: Key-Value Store

#### Dokumentenspeicher

Abstraktion: Schlüssel-Wert-Speicher mit Dokumenten als Werte

Ein Dokumentenspeicher konzentriert sich auf Dokumente (XML, JSON, Binärdateien, usw.), wobei ein Dokument alle Informationen für ein bestimmtes Objekt speichert. Dokumentenspeicher bieten APIs oder eine Abfragesprache, um auf Basis der internen Struktur des Dokuments selbst zu suchen. Beachte, viele Schlüssel-Wert-Speicher bieten Funktionen zur Arbeit mit den Metadaten eines Werts, wodurch die Grenzen zwischen diesen beiden Speichertypen verschwimmen.

Je nach zugrundeliegender Implementierung werden Dokumente nach Sammlungen, Tags, Metadaten oder Verzeichnissen organisiert. Obwohl Dokumente organisiert oder gruppiert werden können, können sie Felder aufweisen, die sich völlig voneinander unterscheiden.

Einige Dokumentenspeicher wie MongoDB und CouchDB bieten auch eine SQL-ähnliche Sprache, um komplexe Abfragen durchzuführen. DynamoDB unterstützt sowohl Schlüssel-Werte als auch Dokumente.

Dokumentenspeicher bieten hohe Flexibilität und werden oft für die Arbeit mit gelegentlich veränderlichen Daten verwendet.

##### Quelle(n) und weiterführende Literatur: Dokumentenspeicher

#### Wide Column Store


Quelle: SQL & NoSQL, eine kurze Geschichte

Abstraktion: verschachtelte Map ColumnFamily>

Die Grundeinheit eines Wide Column Store ist eine Spalte (Name/Wert-Paar). Eine Spalte kann in Spaltenfamilien gruppiert werden (vergleichbar mit einer SQL-Tabelle). Super-Spaltenfamilien gruppieren Spaltenfamilien weiter. Jede Spalte kann unabhängig mit einem Zeilenschlüssel abgerufen werden, und Spalten mit demselben Zeilenschlüssel bilden eine Zeile. Jeder Wert enthält einen Zeitstempel zur Versionierung und zur Konfliktlösung.

Google stellte Bigtable als ersten Wide Column Store vor, was das Open-Source-Projekt HBase im Hadoop-Ökosystem und Cassandra von Facebook beeinflusste. Stores wie BigTable, HBase und Cassandra halten Schlüssel in lexikografischer Reihenfolge und ermöglichen eine effiziente Abfrage von selektiven Schlüsselbereichen.

Wide Column Stores bieten hohe Verfügbarkeit und hohe Skalierbarkeit. Sie werden häufig für sehr große Datensätze eingesetzt.

##### Quelle(n) und weiterführende Literatur: Wide Column Store

#### Graphdatenbank


Quelle: Graphdatenbank

Abstraktion: Graph

In einer Graphdatenbank ist jeder Knoten ein Datensatz und jeder Bogen eine Beziehung zwischen zwei Knoten. Graphdatenbanken sind darauf optimiert, komplexe Beziehungen mit vielen Fremdschlüsseln oder viele-zu-viele-Beziehungen darzustellen.

Graphdatenbanken bieten eine hohe Leistung für Datenmodelle mit komplexen Beziehungen, wie beispielsweise ein soziales Netzwerk. Sie sind relativ neu und werden noch nicht weit verbreitet eingesetzt; es kann schwieriger sein, Entwicklungswerkzeuge und Ressourcen zu finden. Viele Graphen sind nur über REST-APIs zugänglich.

##### Quelle(n) und weiterführende Literatur: Graph

#### Quelle(n) und weiterführende Literatur: NoSQL

SQL oder NoSQL


Quelle: Übergang von RDBMS zu NoSQL

Gründe für SQL:

Gründe für NoSQL:

Beispieldaten, die gut für NoSQL geeignet sind:

##### Quelle(n) und weiterführende Literatur: SQL oder NoSQL

Cache


Quelle: Skalierbare Systemdesign-Muster

Caching verbessert die Ladezeiten von Seiten und kann die Belastung Ihrer Server und Datenbanken verringern. In diesem Modell prüft der Dispatcher zunächst, ob die Anfrage bereits gestellt wurde und versucht, das vorherige Ergebnis zu finden und zurückzugeben, um die tatsächliche Ausführung zu sparen.

Datenbanken profitieren oft von einer gleichmäßigen Verteilung von Lese- und Schreibvorgängen über ihre Partitionen. Beliebte Elemente können die Verteilung verzerren und Engpässe verursachen. Ein Cache vor der Datenbank kann helfen, ungleichmäßige Lasten und Verkehrsspitzen abzufangen.

Client-Caching

Caches können sich auf der Client-Seite (Betriebssystem oder Browser), Server-Seite oder in einer eigenen Cache-Schicht befinden.

CDN-Caching

CDNs werden als eine Art Cache betrachtet.

Webserver-Caching

Reverse Proxies und Caches wie Varnish können statische und dynamische Inhalte direkt ausliefern. Webserver können ebenfalls Anfragen cachen und Antworten zurückgeben, ohne die Anwendungsserver zu kontaktieren.

Datenbank-Caching

Ihre Datenbank enthält normalerweise ein gewisses Maß an Caching in der Standardkonfiguration, optimiert für einen generischen Anwendungsfall. Die Anpassung dieser Einstellungen an spezifische Nutzungsmuster kann die Leistung weiter steigern.

Anwendungs-Caching

In-Memory-Caches wie Memcached und Redis sind Key-Value-Stores zwischen Ihrer Anwendung und Ihrem Datenspeicher. Da die Daten im RAM gehalten werden, ist der Zugriff viel schneller als bei typischen Datenbanken, bei denen die Daten auf Festplatte gespeichert sind. RAM ist begrenzter als Festplattenspeicher, daher können Cache-Invalidierungs-Algorithmen wie Least Recently Used (LRU)) helfen, „kalte“ Einträge zu entfernen und „heiße“ Daten im RAM zu halten.

Redis bietet folgende zusätzliche Funktionen:

Es gibt mehrere Ebenen, auf denen Sie cachen können, die in zwei Hauptkategorien fallen: Datenbankabfragen und Objekte:

Im Allgemeinen sollten Sie dateibasiertes Caching vermeiden, da es das Klonen und Auto-Scaling erschwert.

Caching auf Datenbankabfrage-Ebene

Jedes Mal, wenn Sie die Datenbank abfragen, hashen Sie die Abfrage als Schlüssel und speichern das Ergebnis im Cache. Dieser Ansatz leidet unter Ablaufproblemen:

Caching auf Objektebene

Betrachten Sie Ihre Daten als Objekt, ähnlich wie Sie es mit Ihrem Anwendungscode tun. Lassen Sie Ihre Anwendung den Datensatz aus der Datenbank zu einer Klasseninstanz oder Datenstruktur(en) zusammensetzen:

Vorschläge, was zwischengespeichert werden sollte:

Wann sollte der Cache aktualisiert werden

Da Sie nur eine begrenzte Menge an Daten im Cache speichern können, müssen Sie bestimmen, welche Strategie zur Cache-Aktualisierung am besten für Ihren Anwendungsfall geeignet ist.

#### Cache-aside


Quelle: From cache to in-memory data grid

Die Anwendung ist dafür verantwortlich, aus dem Speicher zu lesen und zu schreiben. Der Cache interagiert nicht direkt mit dem Speicher. Die Anwendung tut Folgendes:

def get_user(self, user_id):
    user = cache.get("user.{0}", user_id)
    if user is None:
        user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id)
        if user is not None:
            key = "user.{0}".format(user_id)
            cache.set(key, json.dumps(user))
    return user
Memcached wird in der Regel auf diese Weise verwendet.

Nachfolgende Lesezugriffe auf in den Cache hinzugefügte Daten sind schnell. Cache-aside wird auch als Lazy Loading bezeichnet. Es werden nur angeforderte Daten zwischengespeichert, wodurch vermieden wird, dass der Cache mit nicht angeforderten Daten gefüllt wird.

##### Nachteil(e): Cache-aside

#### Write-through


Quelle: Skalierbarkeit, Verfügbarkeit, Stabilität, Muster

Die Anwendung verwendet den Cache als Hauptdatenspeicher, liest und schreibt Daten darin, während der Cache für das Lesen und Schreiben in die Datenbank verantwortlich ist:

Anwendungscode:

set_user(12345, {"foo":"bar"})

Cache-Code:

def set_user(user_id, values):
    user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
    cache.set(user_id, user)
Write-through ist insgesamt ein langsamerer Vorgang aufgrund der Schreiboperation, aber nachfolgende Lesevorgänge von gerade geschriebenen Daten sind schnell. Benutzer sind im Allgemeinen toleranter gegenüber Latenz beim Aktualisieren von Daten als beim Lesen von Daten. Daten im Cache sind nicht veraltet.

##### Nachteil(e): Write-through

#### Write-behind (Write-back)


Quelle: Skalierbarkeit, Verfügbarkeit, Stabilitätsmuster

Beim Write-behind führt die Anwendung Folgendes aus:

##### Nachteil(e): Write-behind

#### Refresh-ahead


Quelle: Vom Cache zum In-Memory Data Grid

Der Cache kann so konfiguriert werden, dass kürzlich abgerufene Cache-Einträge automatisch vor deren Ablauf aktualisiert werden.

Refresh-ahead kann zu geringerer Latenz im Vergleich zu Read-through führen, wenn der Cache genau vorhersagen kann, welche Elemente wahrscheinlich zukünftig benötigt werden.

##### Nachteil(e): Refresh-ahead

Nachteil(e): Cache

Quelle(n) und weiterführende Literatur

Asynchronität


Quelle: Intro to architecting systems for scale

Asynchrone Workflows helfen, Anforderungszeiten für aufwendige Operationen zu verkürzen, die sonst inline ausgeführt würden. Sie können auch helfen, indem sie zeitaufwändige Arbeiten im Voraus erledigen, wie z. B. periodische Aggregationen von Daten.

Message Queues

Message Queues empfangen, halten und liefern Nachrichten aus. Wenn eine Operation zu langsam ist, um sie inline auszuführen, kann eine Message Queue mit folgendem Ablauf verwendet werden:

Der Nutzer wird nicht blockiert und der Job wird im Hintergrund verarbeitet. Während dieser Zeit kann der Client optional eine kleine Verarbeitung durchführen, um es so erscheinen zu lassen, als sei die Aufgabe bereits erledigt. Zum Beispiel kann beim Posten eines Tweets der Tweet sofort in deiner Timeline erscheinen, es kann jedoch einige Zeit dauern, bis dein Tweet tatsächlich allen Followern zugestellt wird.

Redis ist als einfacher Message Broker nützlich, aber Nachrichten können verloren gehen.

RabbitMQ ist beliebt, erfordert jedoch die Anpassung an das 'AMQP'-Protokoll und das Verwalten eigener Nodes.

Amazon SQS ist gehostet, kann jedoch eine hohe Latenz aufweisen und es besteht die Möglichkeit, dass Nachrichten doppelt zugestellt werden.

Aufgabenwarteschlangen

Aufgabenwarteschlangen empfangen Aufgaben und die zugehörigen Daten, führen diese aus und liefern dann ihre Ergebnisse. Sie können die Planung unterstützen und werden verwendet, um rechenintensive Jobs im Hintergrund auszuführen.

Celery unterstützt die Planung und bietet hauptsächlich Unterstützung für Python.

Rückstau (Back pressure)

Wenn Warteschlangen signifikant wachsen, kann die Warteschlangengröße größer als der Arbeitsspeicher werden, was zu Cache-Verlusten, Festplattenzugriffen und noch langsamerer Leistung führt. Rückstau kann helfen, indem die Warteschlangengröße begrenzt wird und so eine hohe Durchsatzrate und gute Antwortzeiten für bereits in der Warteschlange befindliche Jobs erhalten bleiben. Sobald die Warteschlange voll ist, erhalten Clients einen „Server busy“- oder HTTP-503-Statuscode, um es später erneut zu versuchen. Clients können die Anfrage zu einem späteren Zeitpunkt erneut senden, eventuell mit exponentiellem Backoff.

Nachteil(e): Asynchronität

Quellen und weiterführende Literatur

Kommunikation


Quelle: OSI 7-Schichten-Modell

Hypertext Transfer Protocol (HTTP)

HTTP ist eine Methode zur Kodierung und Übertragung von Daten zwischen einem Client und einem Server. Es handelt sich um ein Request/Response-Protokoll: Clients stellen Anfragen und Server liefern Antworten mit relevanten Inhalten und Statusinformationen zur Anfrage. HTTP ist selbstständig und ermöglicht, dass Anfragen und Antworten durch viele Zwischenrouter und Server fließen, die Lastverteilung, Caching, Verschlüsselung und Kompression durchführen.

Eine grundlegende HTTP-Anfrage besteht aus einem Verb (Methode) und einer Ressource (Endpunkt). Nachfolgend sind gängige HTTP-Verben aufgeführt:

| Verb | Beschreibung | Idempotent* | Sicher | Cachefähig | |---|---|---|---|---| | GET | Liest eine Ressource | Ja | Ja | Ja | | POST | Erstellt eine Ressource oder löst einen Prozess zur Datenverarbeitung aus | Nein | Nein | Ja, falls die Antwort Frischeinformationen enthält | | PUT | Erstellt oder ersetzt eine Ressource | Ja | Nein | Nein | | PATCH | Aktualisiert eine Ressource teilweise | Nein | Nein | Ja, falls die Antwort Frischeinformationen enthält | | DELETE | Löscht eine Ressource | Ja | Nein | Nein |

*Kann mehrfach aufgerufen werden, ohne unterschiedliche Ergebnisse zu erzeugen.

HTTP ist ein Protokoll der Anwendungsschicht, das auf darunterliegenden Protokollen wie TCP und UDP basiert.

#### Quelle(n) und weiterführende Literatur: HTTP

Transmission Control Protocol (TCP)


Quelle: How to make a multiplayer game

TCP ist ein verbindungsorientiertes Protokoll über ein IP-Netzwerk. Die Verbindung wird mittels eines Handshakes aufgebaut und beendet. Alle gesendeten Pakete sind garantiert in der ursprünglichen Reihenfolge und ohne Fehler am Ziel angekommen durch:

Wenn der Sender keine korrekte Antwort erhält, sendet er die Pakete erneut. Bei mehreren Timeouts wird die Verbindung beendet. TCP implementiert zudem Flusskontrolle) und Staukontrolle. Diese Garantien verursachen Verzögerungen und führen im Allgemeinen zu einer weniger effizienten Übertragung als bei UDP.

Um einen hohen Durchsatz zu gewährleisten, können Webserver viele TCP-Verbindungen offen halten, was zu hohem Speicherverbrauch führt. Es kann teuer sein, viele offene Verbindungen zwischen Webserver-Threads und beispielsweise einem memcached Server zu haben. Connection Pooling kann helfen, zusätzlich zum Wechsel auf UDP, wo dies möglich ist.

TCP ist nützlich für Anwendungen, die hohe Zuverlässigkeit, aber geringere Zeitkritikalität erfordern. Beispiele sind Webserver, Datenbankinformationen, SMTP, FTP und SSH.

Verwenden Sie TCP statt UDP, wenn:

User Datagram Protocol (UDP)


Quelle: How to make a multiplayer game

UDP ist verbindungslos. Datagramme (vergleichbar mit Paketen) sind nur auf Datagramm-Ebene garantiert. Datagramme können ihr Ziel in falscher Reihenfolge erreichen oder gar nicht. UDP unterstützt keine Staukontrolle. Ohne die Garantien, die TCP bietet, ist UDP im Allgemeinen effizienter.

UDP kann Broadcasts durchführen und Datagramme an alle Geräte im Subnetz senden. Dies ist nützlich bei DHCP, da der Client noch keine IP-Adresse erhalten hat und somit verhindert wird, dass TCP ohne IP-Adresse streamt.

UDP ist weniger zuverlässig, funktioniert aber gut in Echtzeit-Anwendungen wie VoIP, Videochat, Streaming und Echtzeit-Mehrspieler-Spielen.

Verwenden Sie UDP anstelle von TCP, wenn:

#### Quelle(n) und weiterführende Literatur: TCP und UDP

Remote Procedure Call (RPC)


Quelle: Crack the system design interview

Bei einem RPC veranlasst ein Client die Ausführung einer Prozedur in einem anderen Adressraum, meist auf einem entfernten Server. Die Prozedur wird so programmiert, als wäre es ein lokaler Prozeduraufruf, wobei die Details der Kommunikation mit dem Server für das Clientprogramm abstrahiert werden. Remote-Aufrufe sind in der Regel langsamer und weniger zuverlässig als lokale Aufrufe, daher ist es hilfreich, RPC-Aufrufe von lokalen Aufrufen zu unterscheiden. Bekannte RPC-Frameworks sind Protobuf, Thrift und Avro.

RPC ist ein Request-Response-Protokoll:

Beispielhafte RPC-Aufrufe:

GET /someoperation?data=anId
POST /anotheroperation
{
  "data":"anId";
  "anotherdata": "another value"
}

RPC konzentriert sich darauf, Verhaltensweisen offenzulegen. RPCs werden häufig aus Leistungsgründen bei interner Kommunikation eingesetzt, da Sie native Aufrufe handhaben können, um sie besser an Ihre Anwendungsfälle anzupassen.

Wählen Sie eine native Bibliothek (auch SDK genannt), wenn:

HTTP-APIs nach REST werden häufiger für öffentliche APIs verwendet.

#### Nachteil(e): RPC

Representational State Transfer (REST)

REST ist ein Architekturstil, der ein Client/Server-Modell erzwingt, bei dem der Client auf einen Satz von Ressourcen zugreift, die vom Server verwaltet werden. Der Server stellt eine Darstellung von Ressourcen und Aktionen bereit, die entweder Ressourcen manipulieren oder eine neue Darstellung von Ressourcen erhalten können. Die gesamte Kommunikation muss zustandslos und cachefähig sein.

Es gibt vier Eigenschaften einer RESTful-Schnittstelle:

Beispielhafte REST-Aufrufe:

GET /someresources/anId
PUT /someresources/anId
{"anotherdata": "another value"}

REST konzentriert sich auf die Bereitstellung von Daten. Es minimiert die Kopplung zwischen Client und Server und wird häufig für öffentliche HTTP-APIs verwendet. REST nutzt eine allgemeinere und einheitlichere Methode zur Bereitstellung von Ressourcen über URIs, Repräsentation über Header und Aktionen über Verben wie GET, POST, PUT, DELETE und PATCH. Da REST zustandslos ist, eignet es sich hervorragend für horizontale Skalierung und Partitionierung.

#### Nachteil(e): REST

Vergleich von RPC- und REST-Aufrufen

| Operation | RPC | REST | |---|---|---| | Anmeldung | POST /signup | POST /persons | | Kündigung | POST /resign
{
"personid": "1234"
} | DELETE /persons/1234 | | Person lesen | GET /readPerson?personid=1234 | GET /persons/1234 | | Liste der Gegenstände einer Person lesen | GET /readUsersItemsList?personid=1234 | GET /persons/1234/items | | Gegenstand zur Liste einer Person hinzufügen | POST /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | POST /persons/1234/items
{
"itemid": "456"
} | | Gegenstand aktualisieren | POST /modifyItem
{
"itemid": "456";
"key": "value"
} | PUT /items/456
{
"key": "value"
} | | Gegenstand löschen | POST /removeItem
{
"itemid": "456"
} | DELETE /items/456 |

Quelle: Do you really know why you prefer REST over RPC

#### Quellen und weiterführende Literatur: REST und RPC

Sicherheit

Dieser Abschnitt könnte ein paar Aktualisierungen gebrauchen. Überlegen Sie, beizutragen!

Sicherheit ist ein umfassendes Thema. Sofern Sie nicht über umfangreiche Erfahrung, einen Sicherheits-Hintergrund verfügen oder sich auf eine Position bewerben, die Sicherheitskenntnisse erfordert, müssen Sie wahrscheinlich nicht mehr als die Grundlagen wissen:

Quelle(n) und weiterführende Literatur

Anhang

Gelegentlich werden Sie gebeten, „Überschlagsrechnungen“ durchzuführen. Zum Beispiel müssen Sie vielleicht abschätzen, wie lange das Erzeugen von 100 Bild-Thumbnails von der Festplatte dauert oder wie viel Speicher eine Datenstruktur benötigt. Die Zweierpotenztabelle und Latenzwerte, die jeder Programmierer kennen sollte sind dabei nützliche Referenzen.

Zweierpotenztabelle

Power           Exact Value         Approx Value        Bytes
---------------------------------------------------------------
7                             128
8                             256
10                           1024   1 thousand           1 KB
16                         65,536                       64 KB
20                      1,048,576   1 million            1 MB
30                  1,073,741,824   1 billion            1 GB
32                  4,294,967,296                        4 GB
40              1,099,511,627,776   1 trillion           1 TB

#### Quelle(n) und weiterführende Literatur

Latenzzahlen, die jeder Programmierer kennen sollte

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy            10,000   ns       10 us
Send 1 KB bytes over 1 Gbps network     10,000   ns       10 us
Read 4 KB randomly from SSD*           150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
HDD seek                            10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from 1 Gbps  10,000,000   ns   10,000 us   10 ms  40x memory, 10X SSD
Read 1 MB sequentially from HDD     30,000,000   ns   30,000 us   30 ms 120x memory, 30X SSD
Send packet CA->Netherlands->CA    150,000,000   ns  150,000 us  150 ms
Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

Praktische Kennzahlen basierend auf den obigen Zahlen:

#### Visualisierung der Latenzzeiten

#### Quelle(n) und weiterführende Literatur

Weitere Fragen zum Systemdesign-Interview

Gängige Fragen zum Systemdesign-Interview mit Links zu Ressourcen, wie man jede löst.

| Frage | Referenz(en) | |---|---| | Entwerfen Sie einen Datei-Sync-Dienst wie Dropbox | youtube.com | | Entwerfen Sie eine Suchmaschine wie Google | queue.acm.org
stackexchange.com
ardendertat.com
stanford.edu | | Entwerfen Sie einen skalierbaren Web-Crawler wie Google | quora.com | | Entwerfen Sie Google Docs | code.google.com
neil.fraser.name | | Entwerfen Sie einen Key-Value-Store wie Redis | slideshare.net | | Entwerfen Sie ein Cache-System wie Memcached | slideshare.net | | Entwerfen Sie ein Empfehlungssystem wie das von Amazon | hulu.com
ijcai13.org | | Entwerfen Sie ein TinyURL-System wie Bitly | n00tc0d3r.blogspot.com | | Entwerfen Sie eine Chat-App wie WhatsApp | highscalability.com | Entwerfen Sie ein Bilder-Sharing-System wie Instagram | highscalability.com
highscalability.com | | Entwerfen Sie die Facebook-Newsfeed-Funktion | quora.com
quora.com
slideshare.net | | Entwerfen Sie die Facebook-Timeline-Funktion | facebook.com
highscalability.com | | Entwerfen Sie die Facebook-Chat-Funktion | erlang-factory.com
facebook.com | | Entwerfen Sie eine Graph-Suchfunktion wie Facebooks | facebook.com
facebook.com
facebook.com | | Entwerfen Sie ein Content Delivery Network wie CloudFlare | figshare.com | | Entwerfen Sie ein Trending Topic System wie das von Twitter | michael-noll.com
snikolov .wordpress.com | | Entwerfen Sie ein System zur zufälligen ID-Generierung | blog.twitter.com
github.com | | Geben Sie die Top-k-Anfragen in einem Zeitintervall zurück | cs.ucsb.edu
wpi.edu | | Entwerfen Sie ein System, das Daten aus mehreren Rechenzentren bereitstellt | highscalability.com | | Entwerfen Sie ein Online-Multiplayer-Kartenspiel | indieflashblog.com
buildnewgames.com | | Entwerfen Sie ein Garbage Collection System | stuffwithstuff.com
washington.edu | | Entwerfen Sie einen API-Rate-Limiter | https://stripe.com/blog/ | | Entwerfen Sie eine Börse (wie NASDAQ oder Binance) | Jane Street
Golang Implementation
Go Implementation | | Fügen Sie eine Systemdesign-Frage hinzu | Contribute |

Architekturen aus der realen Welt

Artikel darüber, wie reale Systeme entworfen werden.


Quelle: Twitter timelines at scale

Konzentrieren Sie sich bei den folgenden Artikeln nicht auf kleinste Details, sondern:

|Typ | System | Referenz(en) | |---|---|---| | Datenverarbeitung | MapReduce - Verteilte Datenverarbeitung von Google | research.google.com | | Datenverarbeitung | Spark - Verteilte Datenverarbeitung von Databricks | slideshare.net | | Datenverarbeitung | Storm - Verteilte Datenverarbeitung von Twitter | slideshare.net | | | | | | Datenspeicher | Bigtable - Verteilte spaltenorientierte Datenbank von Google | harvard.edu | | Datenspeicher | HBase - Open-Source-Implementierung von Bigtable | slideshare.net | | Datenspeicher | Cassandra - Verteilte spaltenorientierte Datenbank von Facebook | slideshare.net | Datenspeicher | DynamoDB - Dokumentenorientierte Datenbank von Amazon | harvard.edu | | Datenspeicher | MongoDB - Dokumentenorientierte Datenbank | slideshare.net | | Datenspeicher | Spanner - Global verteilte Datenbank von Google | research.google.com | | Datenspeicher | Memcached - Verteilter Speicher-Caching-System | slideshare.net | | Datenspeicher | Redis - Verteilter Speicher-Caching-System mit Persistenz und Werttypen | slideshare.net | | | | | | Dateisystem | Google File System (GFS) - Verteiltes Dateisystem | research.google.com | | Dateisystem | Hadoop File System (HDFS) - Open-Source-Implementierung von GFS | apache.org | | | | | | Sonstiges | Chubby - Sperrdienst für locker gekoppelte verteilte Systeme von Google | research.google.com | | Sonstiges | Dapper - Infrastruktur zur Ablaufverfolgung verteilter Systeme | research.google.com | Sonstiges | Kafka - Pub/Sub-Nachrichtenwarteschlange von LinkedIn | slideshare.net | | Sonstiges | Zookeeper - Zentralisierte Infrastruktur und Dienste für Synchronisierung | slideshare.net | | | Architektur hinzufügen | Beitragen |

Unternehmensarchitekturen

| Unternehmen | Referenz(en) | |---|---| | Amazon | Amazon Architektur | | Cinchcast | Produktion von 1.500 Stunden Audio täglich | | DataSift | Echtzeit-Datenanalyse bei 120.000 Tweets pro Sekunde | | Dropbox | Wie wir Dropbox skaliert haben | | ESPN | Betrieb mit 100.000 duh nuh nuhs pro Sekunde | | Google | Google Architektur | | Instagram | 14 Millionen Nutzer, Terabytes an Fotos
Was Instagram antreibt | | Justin.tv | Live-Video-Übertragungsarchitektur von Justin.tv | | Facebook | Memcached-Skalierung bei Facebook
TAO: Facebooks verteiltes Datenspeichersystem für das soziale Netzwerk
Facebooks Foto-Speicherung
Wie Facebook Live Streams für 800.000 gleichzeitige Zuschauer bereitstellt | | Flickr | Flickr Architektur | | Mailbox | Von 0 auf eine Million Nutzer in 6 Wochen | | Netflix | Ein 360-Grad-Blick auf den gesamten Netflix-Stack
Netflix: Was passiert, wenn Sie Play drücken? | | Pinterest | Von 0 auf dutzende Milliarden Seitenaufrufe pro Monat
18 Millionen Besucher, 10-faches Wachstum, 12 Mitarbeiter | | Playfish | 50 Millionen monatliche Nutzer und steigend | | PlentyOfFish | PlentyOfFish Architektur | | Salesforce | Wie sie 1,3 Milliarden Transaktionen pro Tag verarbeiten | | Stack Overflow | Stack Overflow Architektur | | TripAdvisor | 40M Besucher, 200M dynamische Seitenaufrufe, 30TB Daten | | Tumblr | 15 Milliarden Seitenaufrufe pro Monat | | Twitter | Twitter 10.000 Prozent schneller machen
250 Millionen Tweets pro Tag mit MySQL speichern
150M aktive Nutzer, 300K QPS, ein 22 MB/S-Datenstrom
Timelines im großen Maßstab
Große und kleine Daten bei Twitter
Betrieb bei Twitter: Skalierung über 100 Millionen Nutzer hinaus
Wie Twitter 3.000 Bilder pro Sekunde verarbeitet | | Uber | Wie Uber seine Echtzeit-Marktplattform skaliert
Lektionen aus dem Skalieren von Uber auf 2000 Ingenieure, 1000 Services und 8000 Git-Repositories | | WhatsApp | Die WhatsApp-Architektur, die Facebook für 19 Milliarden Dollar kaufte | | YouTube | YouTube Skalierbarkeit
YouTube Architektur |

Ingenieurblogs von Unternehmen

Architekturen von Unternehmen, bei denen Sie sich bewerben.
>
Fragen, denen Sie begegnen, könnten aus demselben Bereich stammen.

#### Quelle(n) und weiterführende Literatur

Möchten Sie einen Blog hinzufügen? Um doppelte Arbeit zu vermeiden, sollten Sie Ihren Firmenblog zu folgendem Repository hinzufügen:

In Entwicklung

Interessiert daran, einen Abschnitt hinzuzufügen oder bei einem laufenden mitzuhelfen? Mitmachen!

Danksagungen

Quellen und Danksagungen sind über dieses Repository verteilt aufgeführt.

Besonderer Dank an:

Kontaktinformationen

Zögern Sie nicht, mich zu kontaktieren, um etwaige Probleme, Fragen oder Kommentare zu besprechen.

Meine Kontaktdaten finden Sie auf meiner GitHub-Seite.

Lizenz

Ich stelle Ihnen Code und Ressourcen in diesem Repository unter einer Open-Source-Lizenz zur Verfügung. Da dies mein persönliches Repository ist, erhalten Sie die Lizenz für meinen Code und meine Ressourcen von mir und nicht von meinem Arbeitgeber (Facebook).

Copyright 2017 Donne Martin

Creative Commons Attribution 4.0 International License (CC BY 4.0)

http://creativecommons.org/licenses/by/4.0/

--- Tranlated By Open Ai Tx | Last indexed: 2025-08-09 ---

Original README: View on GitHub

Translated by OpenAiTx | Last updated: 2025-09-16