czay.dev
0/10
Roadmaps

Entscheidungsmatrix für Backend-Skalierung (0 bis 1 Mio. Nutzer)

Diese interaktive Roadmap begleitet das Video „Die Over-Engineering-Falle: Warum du für kleine Projekte weder Kafka noch Microservices aufsetzen solltest“. Eine der häufigsten Fallen in der Softwareentwicklung: 15 Microservices, Kubernetes und Kafka für ein Projekt ohne einen einzigen aktiven Nutzer aufzusetzen und die ganze Zeit mit dem Debuggen der Infrastruktur zu verbringen, statt das Produkt auszuliefern.

Gute Softwareentwicklung heißt nicht, für jedes Projekt das komplexeste Tool zu wählen, sondern die passendste Lösung mit minimalem Betriebsaufwand und ohne unnötige Komplexität zu bauen. Geh die Stufen unten durch und finde heraus, wann du mit wachsender Nutzerbasis welche Architekturschicht einführst. Dein Fortschritt wird automatisch in deinem Browser gespeichert.

  • KernDas solltest du gut können, bevor du dich bewirbst
  • WünschenswertTaucht oft in Stellenanzeigen auf und verschafft dir einen Vorteil
  • SpäterWenn du im Job bist und es brauchst

Klicke auf ein Thema, um zu sehen, was du wissen musst und wo du es lernen kannst.

  1. 01

    Stufe 1: Sauberer modularer Monolith (0 - 50K DAU)

    Teile die Architektur erst auf, wenn der Product-Market-Fit belegt ist. Ein einziges Deployment, keine Netzwerklatenz, volle ACID-Konsistenz.

  2. 02

    Stufe 2: Datenbank entlasten (50K - 150K DAU)

    Beseitige Engpässe, bevor du Services aufteilst: Ersetze Festplatten-I/O durch RAM-Caching und Read Replicas.

  3. 03

    Stufe 3: Asynchrone Message Queues (150K - 500K DAU)

    Lass Nutzer nie im HTTP-Request warten: Übergib E-Mails, Rechnungserstellung und Webhooks an Background Worker.

  4. 04

    Stufe 4: Domain-Microservices & Event-Driven (500K+ DAU)

    Jetzt ist Zeit für Microservices: Teile nur dann in Domain-Services auf, wenn Teamgröße oder unterschiedliche Skalierungsanforderungen es verlangen.

Thema für Thema

Jedes Thema auf der Karte mit Beschreibung, Wissenswertem und Ressourcen — in einer Liste.

  1. 01Stufe 1: Sauberer modularer Monolith (0 - 50K DAU)

    • Architektur des modularen Monolithen· Kern

      Baue einen einzelnen Monolithen, in dem Domänengrenzen über Ordner (Module) getrennt sind, mit Fastify, NestJS, Go oder Django. Module kommunizieren über In-Memory-Funktionsaufrufe statt über das Netzwerk (0 ms Latenz).

      Das solltest du wissen

      • Module greifen nie direkt auf die Datenbanktabellen anderer Module zu, sondern nur über klar definierte öffentliche Service-Schnittstellen.
      • Ein einzelner, gut konfigurierter Server mit sauber indiziertem PostgreSQL schafft problemlos über 3.500 Anfragen pro Sekunde (RPS).
      • Mit einem einzigen Docker-Image und einer CI/CD-Pipeline lieferst du Updates in Sekunden aus.

      Ressourcen

    • Datenbankindizes & Connection Pooling· Kern

      90 % der langsamer werdenden Systeme leiden an fehlenden Indizes und erschöpften Connection Pools, nicht an zu wenig CPU.

      Das solltest du wissen

      • Lege B-Tree-Indizes auf alle Fremdschlüssel und die üblichen WHERE-/ORDER-BY-Spalten und prüfe Abfragepläne mit EXPLAIN ANALYZE.
      • Setze PgBouncer vor PostgreSQL, um Tausende Client-Verbindungen auf 50-100 Datenbankverbindungen zu bündeln.

      Ressourcen

  2. 02Stufe 2: Datenbank entlasten (50K - 150K DAU)

    • Redis-Cache-Aside-Pattern· Kern

      Cache oft gelesene, selten geänderte Daten (Nutzerprofile, Konfigurationen, Home-Feed) im Redis-RAM. So sinkt die Latenz von 450 ms Festplatten-I/O auf 1,2 ms bei RAM-Treffern.

      Das solltest du wissen

      • Prüfe zuerst Redis (Cache Hit). Fehlt der Eintrag, lies ihn aus der Datenbank, befülle Redis und gib ihn zurück (Cache Miss).
      • Gib Cache-Keys immer sinnvolle TTLs mit; unbegrenztes Caching lässt den Speicher aufblähen.

      Ressourcen

    • Read/Write-Splitting & Read Replicas· Wünschenswert

      Webtraffic besteht typischerweise zu 85 % aus Lesezugriffen (SELECT) und zu 15 % aus Schreibzugriffen (INSERT/UPDATE). Verlagere den Lesetraffic auf Replica-Instanzen.

      Das solltest du wissen

      • Leite Schreiboperationen an die primäre Datenbank und verlagere leselastige Analyse- und Suchabfragen auf Read Replicas.
      • Berücksichtige die Replikationsverzögerung in kritischen Nutzerabläufen (z. B. beim Lesen von Bestelldaten direkt nach dem Checkout).
    • CDN & Verteilung statischer Assets· Kern

      Cache Bilder, Schriftarten, JS/CSS-Bundles und öffentliche API-Antworten auf dem Cloudflare Edge, damit keine Anfragen mehr beim Origin-Server landen.

      Das solltest du wissen

      • Anfragen werden in 10-20 ms an globalen Edge-Knoten beantwortet, bevor sie überhaupt deinen Origin-Server erreichen.

  3. 03Stufe 3: Asynchrone Message Queues (150K - 500K DAU)

    • Job Queues mit BullMQ / RabbitMQ· Kern

      Führe keine Aufgabe, die länger als 50 ms dauert, synchron innerhalb des HTTP-Request-Response-Zyklus aus.

      Das solltest du wissen

      • Löst ein Nutzer eine Aktion aus, stellt die API den Job in die Queue und antwortet in 18 ms mit „200 OK - Accepted“.
      • Dedizierte Background Worker verarbeiten die Queue; stürzt ein Worker ab, bleiben die eingereihten Jobs sicher erhalten.

      Ressourcen

    • Retry-Strategie & Dead Letter Queue (DLQ)· Kern

      Wenn ein Drittanbieter (SendGrid, Stripe) ausfällt, lass die Nutzeranfragen nicht scheitern, sondern wiederhole sie im Hintergrund mit Bedacht.

      Das solltest du wissen

      • Nutze Exponential Backoff mit Jitter, um vorübergehende Fehler sicher zu wiederholen.
      • Leite dauerhaft fehlschlagende Jobs in eine Dead Letter Queue (DLQ) und löse einen Betriebsalarm aus.

  4. 04Stufe 4: Domain-Microservices & Event-Driven (500K+ DAU)

    • Service-Zerlegung nach Domain-Driven Design· Kern

      Zerlege das System nicht über Nacht, sondern löse zuerst die autonomsten Domänen heraus (Auth, Zahlungen, Benachrichtigungen).

      Das solltest du wissen

      • Jeder Service muss seine eigene private Datenbank besitzen (Database-per-Service); gemeinsam genutzte Datenbanken sind ein Anti-Pattern.
      • Teile in Microservices auf, wenn mindestens 5 unabhängige Teams eigenständig und ohne Release-Sperren deployen müssen.

      Ressourcen

    • Event Streaming mit Apache Kafka· Kern

      Synchrone HTTP-Aufrufe zwischen Microservices führen zu Kaskadenfehlern; wechsle zu einer asynchronen Event-Driven-Architektur.

      Das solltest du wissen

      • Wird eine Bestellung angelegt, sende ein „OrderCreated“-Event, statt 5 nachgelagerte REST-Endpoints aufzurufen.
      • Nutze das Transactional Outbox Pattern, um atomare Datenbankupdates und das Veröffentlichen von Events zu garantieren.

      Ressourcen

    • Distributed Tracing & OpenTelemetry· Wünschenswert

      Wenn eine Anfrage über 15 Microservices hinweg 4 Sekunden dauert, sind Correlation IDs und OpenTelemetry-Tracing die einzige Möglichkeit, den Engpass zu finden.

      Das solltest du wissen

      • Erzeuge am API-Gateway eine eindeutige Trace-ID und gib sie in den Headern an alle nachgelagerten Services weiter.