Unter Replikation versteht man das Vorhalten von Kopien derselben Daten auf mehreren Rechnern. Dadurch bleibt der Dienst auch bei Ausfall eines einzelnen Rechners betriebsbereit und kann ein höheres Datenaufkommen bewältigen, als es ein einzelner Rechner leisten könnte.
Um dies zu veranschaulichen, betrachten wir einen einfachen Dienst für Benutzerprofile, der die Operationen GET /profile/{user_id} und PUT /profile/{user_id} unterstützt, um Name, Foto-URL und Einstellungen eines Benutzers abzurufen und zu aktualisieren.
Ein einzelner Server genügt, bis die Profildatenbank zum „Single Point of Failure“ (einem kritischen Einzelpunkt, dessen Ausfall das gesamte System lahmlegt) und zum begrenzenden Faktor für den Durchsatz wird; denn jeder Lese- und Schreibvorgang hängt davon ab, dass dieser eine Rechner einwandfrei und schnell funktioniert.
Die folgende Darstellung definiert unsere Ausgangsbasis, damit wir diese in späteren Lektionen unter Last setzen und beobachten können, an welchen Stellen das System an seine Grenzen stößt.
In diesem Basisszenario rufen Clients den API-Dienst auf, und dieser liest aus einer einzelnen Datenbank und schreibt in sie hinein; ein Datenbankausfall stoppt somit sowohl Lese- als auch Schreibvorgänge, und Lastspitzen konzentrieren sich auf eine einzige CPU und eine einzige Festplatte.
Genau dieser Aspekt macht die Replikation zu einem zentralen Thema bei Design-Gesprächen in Vorstellungsgesprächen: Der Interviewer konzentriert sich darauf, wie das System bei Ausfällen und unter Last reagiert, anstatt auf die konkrete Implementierung eines Endpunkts.
Replikation ist kein einzelnes Feature. Sie umfasst eine Reihe von Entscheidungen, die davon abhängen, was das System im Falle von Teilausfällen gewährleisten muss.
Bei einem Profil-Dienst prüft der Interviewer meist zunächst, ob wir nach den wenigen Anforderungen fragen, die das Replikationsmuster beeinflussen, bevor wir eine bestimmte Technologie nennen.
Die zu klärenden Parameter lassen sich direkt auf die Lese- und Schreibvorgänge übertragen.
Sobald diese Punkte festgelegt sind, ist Replikation kein abstraktes Konzept mehr, sondern Teil einer konkreten Vereinbarung – etwa der Frage, ob GET /profile für einige Sekunden nach einem erfolgreichen PUT /profile noch ein älteres Foto zurückgeben darf.
Nachdem die Anforderungen definiert sind, besteht das einfachste replizierte Design darin, genau eine weitere Datenbankkopie hinzuzufügen und festzulegen, wie Aktualisierungen zwischen den Kopien übertragen werden.
Die Anwendungssemantik bleibt zunächst unverändert. Clients kommunizieren weiterhin mit einer einzigen API-Ebene, und diese API-Ebene löst weiterhin einen einzelnen logischen Schreibvorgang aus, der nicht unbemerkt in widersprüchliche Versionen aufgespalten werden darf.