Drei Jahre bei der Wikimedia Foundation (2022–2025) haben mir beigebracht, dass die Systeme, die ungefähr die Hälfte des Planeten einmal im Monat bedienen, größtenteils unglamouröses PHP, sorgfältiges Caching und operative Kultur sind — kein Architecture-Astronauten-Zeug, das Conference-Talks belohnen. Dieser Post ist ein aufrichtiger Liebesbrief an langweiligen Code in der Skalierung — von jemandem, der drei Jahre im Innern eines der klarsten funktionierenden Beispiele dafür verbracht hat.

Was Wikipedia operativ ist

Wikipedia ist nicht eine Site. Es sind Hunderte von Spracheditions, die auf einer gemeinsamen Codebase (MediaWiki) laufen, backed by einem stark getunten MySQL- Fleet, vorgeschaltet von Varnish und einem Custom-Cache-Layer, serviert über mehrere globale PoPs. Die Engineering-Org ist kleiner, als die meisten Außenstehenden schätzen. Die spendengefinanzierte Foundation hat ein enges Budget, eine tiefe Bank von ehrenamtlichen Contributoren und eine Kultur, die seit über zwanzig Jahren wächst.

Du könntest ein Architekturdiagramm davon in fünf Minuten zeichnen. Bauen könntest du es in weniger als einem Jahrzehnt nicht.

Wie es sich anfühlte, daran zu arbeiten

Ich sage zuerst die unehrliche Sache: Als ich zu Wikimedia kam, erwartete ich, an einem System zu arbeiten, das wie in einem Museum aussehen sollte. Die Realität war eher ein fein gestimmtes Instrument, dessen Stimmung der eigentliche Grund ist, warum es funktioniert. Der Code selbst ist weder der älteste noch der neueste, den ich je angefasst habe. Was einzigartig ist, ist die akkumulierte operative Weisheit, die in jede Entscheidung darüber eingebacken ist, wie der Code läuft.

Konkret:

  • Caching ist First-Class. Jedes Feature beginnt mit “wie cached das?” — nicht als nachgelagertes Performance-Anliegen, sondern als blockierende Designfrage. Wenn ein Feature die Cacheability verschlechtert, ist das ein Design-Gespräch, kein Performance-Tuning-Pass.
  • MySQL ist ein gestimmtes Instrument. Query-Plans werden reviewed. Indizes werden verdient. “Lass uns einfach einen Index hinzufügen” ist keine Sache — Indizes haben laufende Kosten bei dieser Skalierung, und das Gespräch dreht sich darum, ob die Kosten durch das Query-Volumen gerechtfertigt sind, nicht darum, ob der Index die Query schneller macht. Das ist eine Disziplin, die ich bei kleineren Unternehmen nicht gesehen hatte.
  • Deployments werden geprobt. Der Train-Prozess — wie Code jede Woche in Production landet — wurde über ein Jahrzehnt verfeinert. Es ist ein veröffentlichtes Dokument. Jeder weiß, was wann passiert. Es gibt keine Überraschungs-Deploys.
  • Observability ist tief verinnerlicht. Wenn ein Incident passiert, ist das Muskelgedächtnis für das Dashboard, das man öffnet, die Log-Quelle, die man abfragt, den On-Call, den man pagt, über Jahre gebaut worden. Es ist aufgeschrieben. Es wird gedrilled. Neue Engineers lernen es als Ritus, nicht als Referenz.

Keines dieser vier Dinge ist architektonisch. Es sind operative Gewohnheiten, die sich aufaddiert haben. Das ist der echte Burggraben.

Woran ich gearbeitet habe

Ich will meinen Fußabdruck nicht übertreiben. In drei Jahren habe ich zu Verbesserungen bei Performance, Zuverlässigkeit und Observability beigetragen — meistens Backend, meistens in Bereichen, wo meine frühere Erfahrung mit hochdurchsatz-PHP und MySQL sauber übertragen hat. Ich habe kleinere infrastrukturnahe Änderungen geshipt, an Architekturreviews für Systeme teilgenommen, die größer als meine individuelle Urheberschaft waren, und zu Standards-Arbeit beigetragen, die über die Engineering-Org ausgerollt wurde.

Zwei Muster aus dieser Zeit, die ich für immer mitnehmen werde:

1. Architekturreviews als organisatorisches Bindemittel. Wikimedia betreibt einen strukturierten Architekturreview-Prozess. Ein Vorschlag wird geschrieben, umgearbeitet, diskutiert, revidiert und schließlich approved. Das Review ist langsam — manchmal Wochen — und die Langsamkeit ist das Feature. Sie zwingt Vorschläge zu reifen, und sie gibt vielen Contributoren (nicht nur Staff-Engineers) eine Stimme bei der Richtung. Bei kleineren Unternehmen habe ich ähnliche Versuche in Rubber-Stamping verrotten sehen. Bei Wikimedia funktionierte es, weil die Kultur echtes Engagement erwartete. Das ist das fehlende Stück, das die meisten Design-Review-Kulturen fehlt.

2. Ehrenamtliche Contributoren als First-Class-Engineers behandeln. Wikimedias Codebase hat eine Basis ehrenamtlicher Contributoren, die die bezahlten Mitarbeiter bei weitem übertrifft. Jede Design-Entscheidung, jede API-Änderung, jedes Code-Pattern muss lesbar und einladend für Leute sein, die keine Stand-ups mit dir haben. Das ist eine lächerlich gesunde Einschränkung für Engineering-Entscheidungen. Die meisten Pathologien von internen Codebases — clevere Insider-Witze, ungeschriebene Konventionen, magische Abstraktionen — überleben nicht, wenn das Publikum die ganze Welt ist.

Was das mich über Skalierung gelehrt hat

Ich dachte beim Hineinkommen, “Wikipedia-Skalierung” bedeute, das schwierige Problem sei das Traffic-Volumen. Ist es nicht. Das schwierige Problem ist die halbe Million Menschen, die den Inhalt bearbeiten, der seit zwanzig Jahren akkumulierte Content- Graph selbst, und die operative Disziplin, die nötig ist, damit das alles weiter funktioniert, während man noch immer Features shippt.

Der Traffic wird von Varnish serviert. Das ist gelöst.

Das Bearbeitungserlebnis, der Content-Workflow, das mehrsprachige Routing, das Abuse-Prevention-System, die Community-Tools, das Deprecation-Handling, der API- Contract mit Hunderten von Drittanbieter-Tools — das sind die Probleme, die die Engineering-Aufmerksamkeit verbrauchen. Und keines davon wird einfacher, wenn man die langweilige PHP-Codebase wegwirft. Sie würden schlimmer, weil man die akkumulierte Weisheit zusammen mit der Codebase verlieren würde.

Warum ich gegangen bin (und was ich mitgenommen habe)

Ich habe Wikimedia im April 2025 verlassen, um mehr praxisorientierte Arbeit an KI-gestütztem Engineering und local-first Agent-Systemen zu machen — was, in einem Twist, den ich zu schätzen weiß, genau die Art langweiliges-Disziplin-Problem ist, das Wikimedia mich gut zu denken trainiert hat. Eine Agent-Control-Plane (Fulcrum fulcrum) ist architektonisch kein glamouröses System. Es ist eine State-Machine, ein Log, eine Memory-Schicht und ein Orchestrator. Es wird auf dieselbe Art interessant werden, wie Wikipedias Stack interessant ist: in der operativen Disziplin, nicht in der Architektur.

Das Größte, was ich von Wikimedia mitgenommen habe, ist die Überzeugung, dass die meisten “langweiligen” Systeme langweilig sind, weil jemand die Langeweile verdient hat. Jemand hat Jahre damit verbracht, die interessanten Teile abzuzahlen. Jemand hat das Runbook geschrieben. Jemand hat sich für das langsame Architekturreview eingesetzt.

Wenn ich einem einzigen Ratschlag geben könnte, der für den Rest meiner Karriere für jeden Engineer gilt, mit dem ich arbeite: Sei misstrauisch gegenüber aufregenden Systemen. Frag, wer für die Aufregung zahlt. Meistens ist es die On-Call-Rotation — und sie wird aufholen.