- Es wird kritisiert, dass trotz einer geringen Zahl echter Nutzer eine unnötig komplexe Systemarchitektur verwendet wird
- Es werden Beispiele genannt, in denen verschiedene Technologien wie Redis, MongoDB, Kubernetes und Microservices wahllos miteinander kombiniert wurden
- Es wird betont, dass in solchen Fällen oft bereits eine einzelne Postgres-Instanz mit einer einfachen Serverkonfiguration ausreicht
- Komplexität ist keine Tugend; skaliert werden sollte nur dann, wenn die Notwendigkeit nachgewiesen ist
- Der Text erinnert Startups und Entwicklungsteams daran, sich an einfache Designprinzipien passend zur tatsächlichen Größenordnung zu halten
Der Missbrauch unnötiger Tech-Stacks
- Kritisiert werden willkürlich ausgewählte Technologiekombinationen, etwa wenn Redis und MongoDB gleichzeitig eingesetzt werden
- Es werden Fragen gestellt wie: „Warum kommuniziert Redis mit MongoDB?“ und „Warum wird MongoDB überhaupt verwendet?“
- Es wird darauf hingewiesen, dass trotz nur 12 tatsächlicher Nutzer (davon 6 Testkonten) ein verteiltes System eingeführt wurde
- Als Beispiel für übertriebene Skalierung wird ein Fall genannt, in dem eine einzelne Postgres-Instanz vollkommen ausgereicht hätte
Übermaß bei Deployment und Infrastruktur
- Die aktuelle Konfiguration: 15 Microservices, 8 Datenbanken, Kubernetes-Cluster in 3 Umgebungen, 4 Message Queues, Service Mesh, eine 2 Stunden dauernde CI/CD-Pipeline
- Als tatsächlich notwendige Konfiguration werden lediglich ein einzelner Server, Postgres und Redis für Caching genannt
- Damit wird die übermäßige Infrastrukturkomplexität im Vergleich zu den realen Anforderungen klar herausgestellt
Systemkomplexität und Erklärbarkeit
- Wenn man einem Junior-Entwickler das System nur mit einem wie Spaghetti verknoteten Diagramm erklären kann, ist das laut Text ein Problem
- Die Kernaussage wird mit dem Satz „Komplexität ist keine Tugend“ zusammengefasst
- Es wird betont, dass man einfach beginnen und Komplexität nur dann hinzufügen sollte, wenn der Bedarf nachweislich besteht
Zentrale Lehren
- Technologieauswahl und Systemdesign sollten entsprechend Größe und tatsächlicher Nutzung vereinfacht werden
- Unüberlegte Skalierung und die Einführung überladener Tech-Stacks schaden Wartbarkeit und Effizienz
- Für Startups und kleine Teams ist es wichtig, „Einfachheit passend zur Größenordnung“ zu bewahren
1 Kommentare
Hacker-News-Kommentare
Manchmal wirkt so ein Verhalten einfach wie Prokrastination
Weil man nicht mit Kunden, Investoren oder der Rechtsabteilung reden will, macht man stattdessen aus Engineersicht die „interessanten Sachen“
Von außen sieht das produktiv aus, aber in Wahrheit tritt man auf der Stelle
Wenn man nicht jeden Tag bewusst auch die unangenehmen Dinge erledigt, baut man immer weiter ab und steht später vor großen Problemen, die man hätte vermeiden können
Das gilt nicht nur für Software, sondern für das ganze Leben
Ich habe gelernt, dass man, um Geld zu verdienen, nicht die interessanten Dinge tun muss, sondern die wichtigen Dinge mit der richtigen Priorität
Vielleicht geht es eher darum, den Wunsch nach einer idealen Architektur von realitätsfernen CTOs oder VPEs zu bedienen
Ich erinnere mich an Systemdesign-Interviews, in denen man beim Thema Monolith vs. Microservices stark zwischen den Zeilen lesen musste
Am Ende ist meist klar, was die Leute mit Entscheidungsgewalt wollen, und sich dagegenzustellen kostet politisches Kapital
Dann wird mit dem Tech-Stack geprahlt, nach dem Motto: „Ich habe ABC mit XYZ verbunden“
Dahinter steckt auch oft der Wunsch, den Lebenslauf besser aussehen zu lassen
Tatsächlich ließen sich die meisten Projekte schon mit Technik aus den 1990ern umsetzen, aber mit Begriffen wie verteilte Systeme sieht alles viel „cooler“ aus
Wegen der kaputten Hiring-Kultur in der Branche ist es fast so, als würde ein Koch nicht danach beurteilt, wie gut er mit Messern umgehen kann, sondern danach, ob er „Messer einer bestimmten Marke“ benutzt
DuckDuckGo verlangt zum Beispiel nur Algorithmen und Datenstrukturen und sagt lediglich: „Zur Info, wir nutzen Perl“
Stream bietet Bewerbern ohne Go-Kenntnisse einen 10-Wochen-Kurs an, und auch Jane Street verlangt keine OCaml-Erfahrung
Bei bevuta IT GmbH, wo ich arbeite, konnte man Clojure erst nach dem Einstieg lernen
Das ist etwas völlig anderes als diese veralteten Ausschreibungen à la „10 Jahre Ruby on Rails-Erfahrung“
Einfach weil ich etwas Neues ausprobieren und vergleichen wollte
Am Ende ist es Branchenrealität, für ein paar hundert Nutzer über unnötige Komplexität zu reden
„Caching mit Redis“ hört man ständig, aber eigentlich reicht oft auch Postgres
Dass man unbedingt Redis einsetzen will, wirkt so, als könne selbst der Autor seinem Drang zum Overengineering nicht widerstehen
Bei kleinem Maßstab braucht man meist gar keinen Cache, und temporäre Daten in einem separaten System zu halten, ist attraktiver
Auch die Cache-Abstraktionen vieler Frameworks sind in der Regel mit Redis im Hinterkopf entworfen
Am besten startet man mit einem In-Memory-Cache und ergänzt bei Bedarf Redis
Aber Redis/Valkey ist dafür zu viel. memcached ist deutlich einfacher und praktischer
Weil es wie Redis keinen Zustand dauerhaft speichert, vermeidet man schlechte Designmuster, die von Cache-Konsistenz abhängen
Ein DB-Cache ist langsamer, weil er über das Dateisystem gehen muss
Effiziente Queries zu schreiben, ist ein ganz anderes Thema
Wenn man Postgres wieder schnell bekommt, könnte man Redis auch wieder entfernen — meist bleibt es aber einfach drin
In einer auf AWS Lambda basierenden Web-App mit 1000 Requests pro Sekunde war Postgres überfordert, Redis dagegen nicht
Gerade wegen seiner Einfachheit lohnt es sich in Ausnahmefällen
Es ist schon ironisch, dass der Autor für eine Argumentation über „Einfachheit“ eine Seite mit Tailwind + JS-Framework + Bundler gebaut hat
Das hätte man auch als simples HTML umsetzen können
Deshalb stelle ich mein einfaches, selbst verständliches Web-Framework MastroJS vor
Es erzeugt faktisch nur für die verwendeten Utility-Klassen CSS
Der ursprüngliche Tweet stammt von Jeff Atwoods Tweet aus dem Jahr 2013
Ich stehe gerade selbst vor einer ähnlichen Entscheidung
Wenn ein Produkt noch nicht am Markt validiert ist, sollte man klein und schnell starten und ein pivotfähiges MVP bauen
Wenn man Investoren oder Großunternehmen dagegen Kompetenz für skalierbares Design zeigen muss, sollte man von Anfang an eine skalierbare Struktur wählen
Falls das Geschäftsmodell nur funktioniert, wenn es über das hinauswächst, was eine einzelne DB tragen kann, ist eine von Beginn an skalierbare Architektur langfristig sinnvoller
Wer mitten in Infrastruktur-Albträumen arbeitet, für den klingt Einfachheit womöglich weltfremd
Aber viel Komplexität dient weniger technischen als organisatorischen Problemlösungen
Deployment-Automatisierung, Redundanz für Störfälle, CI-Pipelines, Secret-Management, Caching und Ähnliches sind Sicherheitsmechanismen zum Schutz des Teams
Das zu ignorieren, ist riskant, wenn man in Teams arbeitet
Auch SQLite kann produktiv vollkommen ausreichen, aber das Vorurteil „nur für Tests“ ist weit verbreitet
Auch die Standardkonfiguration vieler PaaS-Angebote ist unnötig komplex
Man kann mit einem checklistenbasierten Build-Prozess anfangen und erst automatisieren, wenn dieser stabil läuft
Ich würde gern echte Beispiele sehen, in denen Microservices außerhalb von FAANG-Niveau wirklich notwendig sind
Viele folgen einfach nur dem Standard-Tech-Stack, weil sie Angst davor haben, selbst nachzudenken
Problematisch ist, Kafka, Mongo oder Redis unkritisch einzusetzen
Oft wäre es besser, nur die wirklich benötigten Funktionen selbst zu bauen, und die Fähigkeit, die minimal nötigen Bausteine auszuwählen, ist zentral für gute Engineers
So etwas wie Kafka ist oft schlicht Geldverschwendung
Der Satz „Füge Komplexität nur hinzu, wenn sie nötig ist“ stimmt zwar, aber manchmal ist sie später nur schwer nachzurüsten
Wenn das anfängliche Design falsch war, braucht man womöglich einen kompletten Rewrite
Deshalb ist in der Praxis oft ein Kompromiss wie eine einfache k8s-Konfiguration sinnvoll
Ich hatte kürzlich in einem Interview eine ähnliche Erfahrung
In den letzten 10 Jahren habe ich mich auf PMF (Product-Market Fit) konzentriert und nicht darauf, von Anfang an auf Skalierung fixiert zu sein
Wenn ein Produkt zum Markt passt, kann man Skalierungsprobleme mit Geld lösen
Aber im Interview wurde ich gefragt, wie man einen „Django-Service auf 10 Millionen Requests pro Tag skaliert“
Ich antwortete: „Indem man die Server-Spezifikationen hochschraubt“ — das schien aber keine zufriedenstellende Antwort gewesen zu sein