Warum du für kleine Projekte kein Kafka und keine Microservices brauchst (Over-Engineering)

Es gibt eine verlockende Falle, in die fast jeder Softwareentwickler beim Start eines Greenfield-Projekts tappt: ein System zu entwerfen, das null aktive Nutzer hat, als würden morgen früh zehn Millionen Menschen darauf losgehen.

Du stehst am Architektur-Whiteboard: 12 unabhängige Microservices, ein Apache-Kafka-Cluster für asynchrone Events, getrennte Datenbanken pro Service, gRPC für die Kommunikation zwischen den Services und ein aufwendiges Kubernetes-Mesh, nur damit alles über Wasser bleibt.

Das klingt nach „echtem Engineering“, das man stolz auf LinkedIn zeigen kann. Aber die harte Realität in Production ist simpel: Kafka und Microservices für eine App mit 100 Besuchern am Tag sind kein gutes Engineering, sondern ersticken das Produkt, bevor es seinen ersten Atemzug getan hat.

1. Der Mythos „Netflix macht das auch so“

Die Wurzel dieser Over-Engineering-Epidemie liegt darin, dass man die Engineering-Blogs der Tech-Giganten liest, ohne ihren organisatorischen und betrieblichen Kontext zu verstehen.

Was dabei gern vergessen wird: Weder Netflix noch Uber noch Amazon haben an Tag 1 mit Microservices angefangen.

• Netflix lief jahrelang auf einer monolithischen Architektur, bis ein massiver Datenbankausfall durch Datenkorruption im Jahr 2008 eine Umstellung erzwang. Die Migration zu Microservices war nicht von „cooler Technik“ getrieben, sondern von organisatorischer Skalierung: Hunderte Entwickler, die sich in einem einzigen Repository gegenseitig auf die Füße traten, und eine einzelne Datenbank, die an die physischen Grenzen der Hardware stieß.
• Shopify bewältigt bis heute einen riesigen Anteil des weltweiten Black-Friday-E-Commerce-Traffics mit einem gut durchdachten modularen Monolithen auf Basis von Ruby on Rails.

Wenn du ein Produkt mit einem Team aus 2 bis 5 Entwicklern (oder allein) baust, ist deine größte existenzielle Bedrohung nicht, ob deine Datenbank 100.000 Schreibvorgänge pro Sekunde schafft. Deine größte Bedrohung ist, zu langsam zu sein, nicht iterieren zu können und 80 % deiner Entwicklungskapazität in verteilte Infrastruktur zu stecken, statt Kundennutzen zu liefern.

2. Die versteckte Steuer verfrühter verteilter Systeme

In einer monolithischen Anwendung dauert die Ausführung einer Geschäftstransaktion (await orderService.createOrder()) im Speicher nur Nanosekunden. Geht mittendrin etwas schief, stellt eine normale Datenbanktransaktion (ROLLBACK) den Zustand deterministisch wieder her.

In dem Moment, in dem du in Microservices und einen Event-Bus wie Kafka aufteilst, erbst du einen ganzen Katalog an Albträumen verteilter Systeme:

1. Verteilte Transaktionen & Saga-Patterns: Der Payment-Service hat die Kreditkarte belastet, aber der Inventory-Service ist abgestürzt, bevor er den Bestand reservieren konnte. Wie stellst du zuverlässig kompensierende Transaktionen aus?
2. Netzwerklatenz & Unzuverlässigkeit: Funktionsaufrufe im Speicher im Submillisekundenbereich werden zu HTTP/gRPC-Roundtrips von 20–50 ms über ein Netzwerk, das von Natur aus unzuverlässig ist.
3. Observability-Albtraum: Um einen Bug aufzuspüren, brauchst du jetzt Distributed Tracing (OpenTelemetry, Jaeger) und eine zentrale Logging-Infrastruktur, nur um herauszufinden, welche Queue eine Nachricht verloren hat.
4. Deployment-Lähmung: Statt ein einzelnes Binary oder einen Container mit einem Befehl zu deployen, orchestrierst du serviceübergreifende Schema-Migrationen, API-Versionierung und komplexe CI/CD-Matrizen.

3. Die pragmatische Skalierungsleiter

Was ist also die pragmatische Alternative? Wie solltest du deine Backend-Infrastruktur mit wachsender Nutzerzahl tatsächlich weiterentwickeln?

      ▲
     / \     Stage 4: 1M+ DAU & Multiple Independent Teams
    /   \    ➔ Event-Driven (Kafka), Kubernetes, Polyglot Microservices
   /-----\   
  /       \   Stage 3: 250k - 1M DAU
 /         \  ➔ Read-Replicas, Asynchronous Queues (BullMQ / RabbitMQ)
/-----------\ 
/             \ Stage 2: 50k - 250k DAU
/               \ ➔ Redis Cache (Cache-Aside), Connection Pooling (PgBouncer)
/-----------------/                   \ Stage 1: 0 - 50k DAU
/                     \ ➔ Modular Monolith + Single Managed PostgreSQL

Stufe 1: 0 – 50.000 DAU (sauberer modularer Monolith)

• Architektur: Eine einzelne Anwendung in Node.js (Fastify/NestJS), Go oder Python.
• Datenbank: Eine einzelne verwaltete PostgreSQL- oder MySQL-Instanz.
• Strategie: Schreibe modularen Code mit klaren Domänengrenzen, keinen Spaghetti-Code. Falls du später doch einen Service herauslösen musst, existieren die Grenzen bereits – lass sie aber heute im selben Prozess laufen. Dieses Setup bewältigt problemlos zehntausende täglich aktive Nutzer mit Latenzen unter 50 ms auf einem VPS für 20 $ im Monat.

Stufe 2: 50.000 – 250.000 DAU (Caching & Verbindungsmanagement)

• Engpass: Wiederholte Leseabfragen treiben die CPU-Auslastung der Datenbank in die Höhe.
• Lösung:
  • Setze Redis mit dem Cache-Aside-Pattern vor die Datenbank. Häufige Lesezugriffe werden direkt aus dem RAM in 1–2 Millisekunden bedient.
  • Führe PgBouncer oder Connection Pooling ein, um bei Traffic-Spitzen eine Erschöpfung der Verbindungen zu verhindern.

Stufe 3: 250.000 – 1.000.000 DAU (Read/Write-Split & asynchrone Worker)

• Engpass: Synchrone, aufwendige Aufgaben (E-Mails versenden, Uploads verarbeiten, Berichte erzeugen) blockieren API-Threads. Lesezugriffe überlasten den primären Knoten der Datenbank.
• Lösung:
  • Lagere unkritische Aufgaben in schlanke Background-Job-Queues wie BullMQ oder RabbitMQ aus.
  • Füge der Datenbank 1–2 Read Replicas hinzu und leite leselastige Abfragen vom Schreib-Master weg.

Stufe 4: 1.000.000+ DAU (Event-Driven & Domain-Extraktion)

• Warum jetzt? Unabhängige Engineering-Teams (Payments, Suche, Identity) müssen deployen können, ohne sich gegenseitig in die Quere zu kommen, und Audit-Logs erzeugen Terabytes an sequenziellen Events.
• Lösung: Jetzt sind Kafka, Event-Streaming und dedizierte Microservices gerechtfertigt, denn die organisatorischen und architektonischen Engpässe übersteigen endlich die Betriebskosten.

Du weißt nicht, welche Stufe dein Projekt braucht?

Wenn du interaktiv herausfinden willst, wo dein aktuelles Nutzeraufkommen liegt, welche Engpässe als Nächstes anstehen und welche Tools für jede Phase empfohlen werden, wirf einen Blick auf unsere interaktive Roadmap:

👉 Die interaktive Entscheidungsmatrix zur Backend-Skalierung erkunden

Fazit

Die beste Architektur ist nie die mit den meisten beweglichen Teilen. Die beste Architektur ist die, die Geschäftsziele mit der geringsten Komplexität und der höchsten Entwicklungsgeschwindigkeit erreicht.

Investiere die zwei Monate, die du mit der Konfiguration von Kafka und Kubernetes vergeudet hättest, in die Verbesserung deiner User Experience. Halte deinen Monolithen sauber und modular; wenn der Traffic kommt, ist es viel einfacher – und unendlich angenehmer –, ihn systematisch zu skalieren.