Systemdesign-Grundlagen, die jeder Entwickler kennen sollte

Jeder Backend-Entwickler stoesst irgendwann an eine Wand. Die Anwendung funktioniert einwandfrei auf Ihrem Laptop. Sie funktioniert einwandfrei im Staging mit drei gleichzeitigen Benutzern. Dann deployen Sie in die Produktion, tausend Leute erscheinen auf einmal, und die Datenbank bricht zusammen. Die API beginnt, 5xx-Fehler zurueckzugeben, das Frontend haengt, und irgendwo in Slack postet jemand den Screenshot, der Ihr Telefon um 2 Uhr morgens vibrieren laesst.

Systemdesign ist das, was auf der anderen Seite dieser Wand lebt. Es ist die Sammlung von Mustern, Kompromissen und Infrastrukturentscheidungen, die eine Spielzeuganwendung von einem Produktionssystem unterscheiden, das echten Datenverkehr bewaltigen kann, ohne zusammenzubrechen. Die gute Nachricht ist, dass Sie kein erfahrener Infrastruktur-Ingenieur sein muessen, um die Grundlagen zu verstehen. Sie muessen etwa acht Konzepte kennen, wie sie zusammenwirken und wann Sie zu welchem greifen.

Dieser Artikel behandelt die Systemdesign-Muster, die fuer arbeitende Backend-Entwickler am wichtigsten sind. Jeder Abschnitt erklaert das Konzept, zeigt ein praktisches Beispiel und beschreibt die Kompromisse, die Sie vor der Einfuehrung bewerten muessen. Dies sind keine abstrakten Lehrbuchkonzepte - es sind Werkzeuge, zu denen Sie jedes Mal greifen werden, wenn Sie etwas bauen, das skalieren muss.

Load Balancing - Jeden Server beschaeftigen, aber nicht ueberlasten

Load Balancing ist das einfachste und wirkungsvollste Systemdesign-Muster, das Sie implementieren koennen. Die Idee ist einfach: Anstatt den gesamten Datenverkehr an einen einzelnen Server zu senden, verteilen Sie eingehende Anfragen auf einen Pool von Servern. Das bringt zwei Vorteile gleichzeitig: hoehere Verfuegbarkeit (wenn ein Server ausfaellt, bedienen die anderen weiter) und hoeheren Durchsatz (mehrere Server teilen sich die Arbeit).

Die gebraeuchlichsten Load-Balancing-Algorithmen sind Round-Robin, Least Connections und IP-Hash. Round-Robin durchlaeuft die Serverliste der Reihe nach - einfach, vorhersagbar, aber ohne Wissen darueber, wie ausgelastet jeder Server tatsaechlich ist. Least Connections sendet jede Anfrage an den Server mit den wenigsten aktiven Verbindungen, was ungleiche Anforderungslasten besser handhabt. IP-Hash verwendet die IP-Adresse des Clients, um deterministisch einen Server auszuwaehlen, was wichtig ist, wenn Sie sticky Sessions benoetigen - um sicherzustellen, dass derselbe Client immer denselben Server trifft.

In der Praxis verwenden die meisten Produktions-Setups eine Kombination. Ein Layer-4-Load-Balancer (auf TCP-Ebene) verteilt rohe Verbindungen auf einen Pool von Reverse-Proxys oder API-Gateways, die dann Layer-7-Load-Balancing (auf HTTP-Ebene) durchfuehren, um Anfragen an bestimmte Anwendungsinstanzen weiterzuleiten. Dieser geschichtete Ansatz haelt die Datenebene schnell und die Routing-Logik flexibel.

# nginx.conf — simple round-robin load balancing across three app servers
upstream app_cluster {
    round-robin;
    server app1.internal:3000 max_fails=3 fail_timeout=30s;
    server app2.internal:3000 max_fails=3 fail_timeout=30s;
    server app3.internal:3000 max_fails=3 fail_timeout=30s;
}

server {
    listen 443 ssl;
    location / {
        proxy_pass http://app_cluster;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Das kritische Detail, das die meisten Entwickler uebersehen, ist der Health Check. Ein Load Balancer ist nur nuetzlich, wenn er weiss, welche Server gesund sind. Wenn app2 abstuerzt, der Load Balancer aber weiterhin Traffic dorthin sendet, steigt Ihre Fehlerrate um etwa ein Drittel. Konfigurieren Sie immer aktive Health Checks - der Load Balancer pingt jeden Server regelmaessig an und entfernt nicht reagierende Server automatisch aus dem Pool.

Caching - Geschwindigkeit, aber zu welchem Preis?

Caching ist die einzelne Optimierung mit der groessten Hebelwirkung, die jedem Entwickler zur Verfuegung steht. Ein einziger Cache-Treffer kann eine 200 Millisekunden dauernde Datenbankabfrage in einen 2 Millisekunden dauernden Speicherzugriff verwandeln. Zwei Groessenordnungen. Angewendet auf Millionen von Anfragen ist dieser Unterschied der Unterschied zwischen einer monatlichen Datenbankrechnung von 10.000 $ und einer von 500 $.

Der kanonische Caching-Stack hat drei Ebenen mit unterschiedlichen Eigenschaften. Anwendungs-Caching (In-Memory-Caches wie Redis oder Memcached) speichert die Ergebnisse teurer Berechnungen oder Datenbankabfragen. CDN-Caching speichert statische und halbstatische Assets an Edge-Standorten nahe der Benutzer. HTTP-Caching verwendet Cache-Control- und ETag-Header, damit Browser und Proxys Antworten cachen koennen, ohne Ihre Server zu involvieren.

Der schwierigste Teil des Cachings ist nicht das Einrichten, sondern das Invalidieren des Caches, wenn sich die zugrundeliegenden Daten aendern. Die Branche hat sich auf einige zuverlaessige Muster geeinigt. Cache-aside (auch Lazy Loading genannt) bedeutet, dass die Anwendung zunaechst den Cache ueberprueft, bei einem Fehlschlag auf die Datenbank zurueckgreift und den Cache mit dem Ergebnis befuellt. Write-Through-Cache bedeutet, dass jeder Schreibvorgang gleichzeitig in den Cache und die Datenbank geht. Write-Behind-Cache bedeutet, dass Schreibvorgaenge zunaechst in den Cache gehen und asynchron in die Datenbank uebertragen werden.

Es gibt nur zwei schwierige Dinge in der Informatik: Cache-Invalidierung und die Benennung von Dingen. Cache-Invalidierung ist schwieriger, weil man sie nicht einfach umbenennen und hoffen kann, dass sie verschwindet.

Fuer die meisten Anwendungen ist Cache-aside mit einer kurzen Time-to-Live die richtige Voreinstellung. Setzen Sie einen TTL, der Ihrer Toleranz fuer veraltete Daten entspricht - 60 Sekunden fuer Benutzerprofile, 5 Minuten fuer Produktlisten, 24 Stunden fuer Referenzdaten. Wenn Sie staerkere Konsistenz benoetigen, verwenden Sie einen Write-Through-Cache, akzeptieren aber die hoehere Schreiblatenz. Wenn Sie maximalen Lese-Durchsatz benoetigen und eventuelle Konsistenz tolerieren koennen, verwenden Sie Cache-aside mit einem grosszuegigen TTL.

import redis.asyncio as aioredis
import json

cache = aioredis.Redis.from_url("redis://cache:6379")

CACHE_TTL = 300  # 5 minutes

async def get_user_profile(user_id: str) -> dict:
    key = f"profile:{user_id}"
    cached = await cache.get(key)
    if cached:
        return json.loads(cached)
    profile = await db.fetch_user(user_id)
    if profile:
        await cache.setex(key, CACHE_TTL, json.dumps(profile))
    return profile

Ein Wort der Warnung: Caching kann Probleme verschleiern, anstatt sie zu loesen. Wenn Ihre Datenbankabfragen langsam sind, weil ein Index fehlt, versteckt das Hinzufuegen eines Caches das Symptom, aber die zugrundeliegende Abfrage bleibt langsam. Der Cache wird evakuiert, die langsame Abfrage laeuft, der Benutzer wartet. Profilen und optimieren Sie immer zunaechst Ihre langsamen Pfade, dann fuegen Sie Caching oben auf die optimierte Version.

Datenbank-Sharding - Die Arbeit aufteilen, damit keine einzelne Datenbank untergeht

Sharding (horizontale Partitionierung) ist das Mittel der Wahl, wenn eine einzelne Datenbankinstanz Ihren Schreibdurchsatz oder Ihre Datengroesse nicht bewltigen kann. Die Idee ist, Ihre Daten auf mehrere Datenbankinstanzen aufzuteilen, wobei jede Instanz (Shard) eine Teilmenge der Daten haelt. Die Anwendung bestimmt anhand eines Shard-Keys, welchen Shard sie abfragen muss - typischerweise ein Hash der Benutzer-ID, eine geografische Region oder ein Zeitbereich.

Der Shard-Key ist die wichtigste Einzelentscheidung in jedem Sharding-System. Ein guter Shard-Key verteilt die Daten gleichmassig auf die Shards und passt zu Ihren Abfragemustern. Ein schlechter Shard-Key erzeugt heisse Shards - einige wenige Shards, die den Grossteil des Datenverkehrs bewaltigen, waehrend der Rest ungenutzt bleibt. Zum Beispiel klingt Sharding nach Erstellungszeitstempel vernuenftig, bis man feststellt, dass der heutige Shard alle Schreibvorgaenge verarbeitet, waehrend die Shards vom letzten Jahr keine verarbeiten.

Konsistentes Hashing loest das Problem der Neuverteilung, das naives Sharding plagt. In einem einfachen modulo-basierten Sharding-Schema (Shard = hash(Key) % N) erfordert das Hinzufuegen eines neuen Shards das Umschichten fast aller Daten. Konsistentes Hashing bildet sowohl Schluessel als auch Shards auf einen Hash-Ring ab; wenn Sie einen Shard hinzufuegen, muessen nur die Schluessel in der unmittelbaren Nachbarschaft des neuen Shards verschoben werden. Das macht das Hoch- und Herunterskalieren viel weniger schmerzhaft.

• Hash-basiertes Sharding - Verteilung durch Hashing des Shard-Keys; einfach und gleichmassig, aber Resharding ist teuer
• Bereichsbasiertes Sharding - Aufteilung nach Wertebereichen (z.B. Benutzer mit IDs 1-10000 auf Shard A, 10001-20000 auf Shard B); effizient fuer Bereichsabfragen, aber anfaellig fuer heisse Punkte
• Verzeichnisbasiertes Sharding - Verwaltung einer Nachschlagetabelle, die Schluessel auf Shards abbildet; flexibel, fuegt aber einen Nachschlage-Schritt und einen einzelnen Ausfallpunkt hinzu, wenn das Verzeichnis ausfaellt
• Geografisches Sharding - Aufteilung nach Benutzerregion; hervorragend fuer Latenz, aber ungeeignet, wenn Benutzer reisen oder wenn Daten global sein muessen

Der Kompromiss, den Sie mit Sharding eingehen, ist, dass abfragen ueber mehrere Shards hinweg teuer oder unmoeglich werden. Wenn Sie Ihre Benutzertabelle nach user_id und Ihre Bestellungstabelle nach user_id sharden, muss eine Abfrage aller Bestellungen der letzten 30 Tage jeden Shard treffen. Anwendungen, die globale Analysen oder abfragen ueber Shards hinweg benoetigen, verwenden oft eine sekundaere Read-Replica (oder eine dedizierte Analysedatenbank), die Daten von allen Shards asynchron aggregiert.

Das CAP-Theorem - Sie koennen nur zwei waehlen

Das CAP-Theorem besagt, dass ein verteilter Datenspeicher nicht gleichzeitig mehr als zwei von drei Garantien bieten kann: Konsistenz (jede Leseoperation erhaelt den neuesten Schreibzugriff), Verfuegbarkeit (jede Anfrage erhaelt eine Antwort, auch wenn es nicht die aktuellsten Daten sind) und Partitionstoleranz (das System arbeitet trotz Netzwerkausfaellen zwischen Knoten weiter).

In der Praxis ist Partitionstoleranz nicht optional. Netzwerke fallen aus. Pakete werden verloren, Verbindungen brechen ab, Rechenzentren verlieren den Strom. Die eigentliche Wahl ist also zwischen CP (Konsistenz + Partitionstoleranz) und AP (Verfuegbarkeit + Partitionstoleranz). Ein CP-System wie etcd oder Zookeeper verweigert Lesevorgaenge, wenn es keine Konsistenz zwischen den Knoten garantieren kann. Ein AP-System wie Cassandra oder DynamoDB bedient Lesevorgaenge von jedem erreichbaren Knoten, auch wenn dieser Knoten veraltete Daten hat.

Dies ist keine akademische Unterscheidung. Wenn Sie ein System entwerfen, das sich ueber mehrere Rechenzentren erstreckt, muessen Sie entscheiden, was passiert, wenn die Netzwerkverbindung zwischen ihnen ausfaellt. Bedienen Sie weiterhin Anfragen mit potenziell veralteten Daten (AP)? Oder stellen Sie den Dienst ein, bis das Netzwerk wiederhergestellt ist (CP)? Die Antwort haengt von Ihrer Anwendung ab. Ein Content Delivery Network sollte AP sein - veraltete Inhalte sind besser als keine Inhalte. Ein Zahlungsabwicklungssystem sollte CP sein - Sie moechten einen Kunden niemals doppelt belasten, weil zwei Knoten waehrend einer Partitionierung dieselbe Zahlung akzeptiert haben.

Message Queues - Synchrone Schmerzen in asynchrone Anmut verwandeln

Message Queues sind das Rueckgrat der asynchronen Verarbeitung in verteilten Systemen. Sie ermoeglichen es einem Dienst (dem Produzenten), eine Nachricht an eine Warteschlange zu senden, ohne darauf zu warten, dass der Konsument sie verarbeitet. Der Konsument nimmt die Nachricht entgegen, wenn er bereit ist, verarbeitet sie und bestaetigt den Abschluss. Dies entkoppelt den Produzenten vom Konsumenten sowohl zeitlich als auch raeumlich - sie muessen nicht mit derselben Geschwindigkeit oder sogar zur selben Zeit laufen.

Jedes nicht-triviale Backend-System sollte irgendwo eine Message Queue verwenden. Das kanonische Beispiel ist der E-Mail-Versand. Wenn sich ein Benutzer auf Ihrer Plattform registriert, moechten Sie nicht, dass die HTTP-Antwort darauf wartet, dass der E-Mail-Zustelldienst eine Vorlage rendert, eine Verbindung zu SendGrid herstellt und die Nachricht zustellt. Stattdessen schickt Ihre API ein send_email-Ereignis in eine Warteschlange und gibt sofort eine 201 Created-Antwort zurueck. Ein separater Worker nimmt das Ereignis auf, sendet die E-Mail und markiert die Aufgabe als erledigt.

Die beiden vorherrschenden Message-Queue-Modelle sind Publish-Subscribe (Pub/Sub) und Work Queues. Bei Pub/Sub wird jede Nachricht an alle Abonnenten gesendet. Dies ist nuetzlich fuer ereignisgesteuerte Architekturen, in denen mehrere Dienste auf dasselbe Ereignis reagieren muessen - eine neue Benutzerregistrierung koennte gleichzeitig eine Willkommens-E-Mail, eine CRM-Aktualisierung und ein Analyseereignis ausloesen. In einer Work Queue wird jede Nachricht an genau einen Konsumenten zugestellt. Dies ist nuetzlich fuer die Verteilung von Arbeit auf einen Pool von Workern - jeder Bild-Upload geht an genau einen Thumbnail-Generator.

# docker-compose.yml — minimal RabbitMQ setup for local development
version: "3.8"
services:
  rabbitmq:
    image: rabbitmq:3-management-alpine
    ports:
      - "5672:5672"   # AMQP port for producers/consumers
      - "15672:15672" # Management UI
    environment:
      RABBITMQ_DEFAULT_USER: app
      RABBITMQ_DEFAULT_PASS: dev-only-password
    volumes:
      - rabbitmq_data:/var/lib/rabbitmq

volumes:
  rabbitmq_data:

Der knifflige Teil bei Message Queues ist der elegante Umgang mit Fehlern. Was passiert, wenn der Konsument mitten in der Verarbeitung einer Nachricht abstuerzt? RabbitMQ und Amazon SQS handhaben dies mit Zusendungsbestaetigungen - der Konsument muss explizit bestaetigen, dass eine Nachricht erfolgreich verarbeitet wurde. Wenn der Konsument die Verbindung trennt, ohne zu bestaetigen, wird die Nachricht wieder in die Warteschlange gestellt und an einen anderen Konsumenten zugestellt. Diese Mindestens-einmal-Zusendungsgarantie bedeutet, dass Ihre Konsumenten idempotent sein muessen: Die zweimalige Verarbeitung derselben Nachricht muss dasselbe Ergebnis liefern wie die einmalige Verarbeitung.

Dead Letter Queues sind ein weiteres wesentliches Muster. Wenn eine Nachricht nach mehreren Wiederholungsversuchen nicht verarbeitet werden kann (der nachgelagerte Dienst ist ausgefallen, die Daten sind fehlerhaft, die Geschaeftsregel hat sich geaendert), wird die Nachricht in eine Dead Letter Queue verschoben, anstatt unendlich oft wiederholt zu werden. Ein Operator ueberwacht die Dead Letter Queue, untersucht die Ursache und entweder korrigiert die Nachricht und stellt sie erneut in die Warteschlange oder verwirft sie, nachdem bestaetigt wurde, dass sie ignoriert werden kann.

CDNs und Rate Limiting - Die Frontline-Verteidigung

Content Delivery Networks und Rate Limiter dienen unterschiedlichen Zwecken, aber sie haben eine Gemeinsamkeit: Sie sind die erste Verteidigungslinie zwischen Ihren Benutzern und Ihren Servern. Ein CDN haelt statische Assets und zwischengespeicherte Antworten nahe am Benutzer, reduziert die Latenz und entlastet Ihre Urspungsserver. Ein Rate Limiter verhindert, dass ein einzelner Benutzer oder Client Ihr System mit Anfragen ueberlastet.

CDNs funktionieren, indem sie Ihre Inhalte auf ein globales Netzwerk von Edge-Servern verteilen. Wenn ein Benutzer in Tokio ein Asset anfordert, bedient das CDN es vom naechstgelegenen Edge-Standort, anstatt die Anfrage den ganzen Weg zu Ihrem Urspungsserver in Virginia zu leiten. Dies reduziert die Latenz fuer statische Assets von 200 Millisekunden auf 10 Millisekunden. Moderne CDNs gehen noch weiter - sie koennen API-Antworten cachen, TLS-Verbindungen terminieren und sogar serverlose Funktionen am Edge ausfuehren.

Rate Limiting schuetzt Ihr System auf mehreren Ebenen. Globales Rate Limiting begrenzt die Gesamtzahl der Anfragen, die Ihr gesamtes System pro Sekunde verarbeiten kann, und schuetzt vor Traffic-Spitzen und DDoS-Angriffen. Benutzerbezogenes Rate Limiting stellt sicher, dass ein einziger missbraeuchender Mandant anderen Benutzern nicht die Ressourcen entzieht. Endpunktbezogenes Rate Limiting wendet unterschiedliche Grenzen auf verschiedene Routen an - ein Login-Endpunkt erlaubt vielleicht 5 Anfragen pro Minute, waehrend ein schreibgeschuetzter Such-Endpunkt 100 Anfragen pro Minute erlaubt.

Der Sliding-Window-Algorithmus ist der Industriestandard fuer Rate Limiting, da er sowohl genau als auch effizient ist. Anstatt Zaehler in festen Intervallen zurueckzusetzen (was Ausbrueche an der Grenze ermoeglicht), beruecksichtigt ein Sliding Window Anfragen ueber ein rollierendes Zeitfenster. Redis ist die natuerliche Wahl fuer die Implementierung - verwenden Sie eine sortierte Menge mit Zeitstempeln als Bewertungen, entfernen Sie Eintraege ausserhalb des Fensters und zaehlen Sie die verbleibenden Eintraege. Der Speicherbedarf ist minimal (ein paar Bytes pro Anfrage) und die Zeitkomplexitaet ist logarithmisch.

// Redis-backed sliding window rate limiter (TypeScript)
import { createClient } from "redis";

const redis = createClient({ url: "redis://ratelimit:6379" });

async function checkRateLimit(
  key: string,
  limit: number,
  windowMs: number
): Promise<{ allowed: boolean; remaining: number }> {
  const now = Date.now();
  const windowStart = now - windowMs;

  const multi = redis.multi();
  multi.zRemRangeByScore(key, 0, windowStart);
  multi.zAdd(key, { score: now, value: `${now}` });
  multi.zCard(key);
  multi.expire(key, Math.ceil(windowMs / 1000));

  const [, , count] = await multi.exec() as [any, any, number];
  return {
    allowed: count <= limit,
    remaining: Math.max(0, limit - count),
  };
}

Sowohl CDNs als auch Rate Limiter teilen ein wichtiges Betriebsprinzip: Fail Open oder Fail Closed? Wenn der CDN-Edge den Urspung nicht erreichen kann, soll er eine veraltete zwischengespeicherte Antwort ausliefern (Fail Open) oder einen Fehler zurueckgeben (Fail Closed)? Wenn der Redis-Cluster des Rate Limiters ausfaellt, sollen alle Anfragen durchgelassen werden (Fail Open - Risiko der Ueberlastung) oder alle Anfragen abgelehnt werden (Fail Closed - garantierte Ausfallzeit)?

Es gibt keine universelle Antwort, aber eine gute Voreinstellung fuer die meisten Systeme ist: Fail Open fuer Lesevorgaenge, Fail Closed fuer Schreibvorgaenge. Eine veraltete Produktlistenseite ist akzeptabel. Ein verlorener Kaufauftrag ist es nicht. Dokumentieren Sie diese Entscheidung explizit in Ihrem Runbook, damit der Bereitschaftsingenieur weiss, welches Verhalten zu erwarten ist, wenn die Infrastruktur nachgibt.

Alles zusammennehmen - Denken in Kompromissen

Systemdesign bedeutet nicht, Muster auswendig zu lernen. Es geht darum, Kompromisse zu verstehen und zu erkennen, welches Muster zu Ihren Einschraenkungen passt. Jede Entscheidung beinhaltet einen Kompromiss zwischen Konsistenz und Verfuegbarkeit, zwischen Lese-Durchsatz und Schreib-Latenz, zwischen operationeller Komplexitaet und roher Leistung. Die besten Ingenieure sind nicht diejenigen, die die meisten Muster kennen - sie sind diejenigen, die ein Problem betrachten und erkennen koennen, welche Einschraenkungen fest und welche verhandelbar sind.

Hier ist ein schneller Entscheidungsrahmen fuer den Fall, dass Sie vor einem neuen Systemdesign-Problem stehen. Beginnen Sie mit der Auflistung Ihrer nicht-funktionalen Anforderungen: erwartetes Datenverkehrsvolumen, Latenzziele, Konsistenzanforderungen, Budget fuer Infrastrukturkosten und Vertrautheit des Teams mit der Technologie. Arbeiten Sie dann die Muster in diesem Artikel durch und fragen Sie, ob jedes Sie Ihren Anforderungen naeher bringt oder sie weiter entfernt.

Wenn Latenz Ihr Hauptanliegen ist, beginnen Sie mit Caching und einem CDN - sie bringen die groesste Verbesserung bei geringster Komplexitaet. Wenn Verfuegbarkeit kritisch ist, verwenden Sie Load Balancing mit Health Checks, entwerfen Sie Ihre Dienste zustandslos und waehlen Sie AP ueber CP, wo es das Geschaeft erlaubt. Wenn Sie mit schreibintensiven Workloads zu tun haben, bewerten Sie Sharding und Message Queues fruehzeitig - sie sind viel einfacher zu implementieren, bevor Sie Millionen von Datenzeilen haben. Wenn Sie mit einer oeffentlichen API arbeiten, die von Drittanbieter-Entwicklern genutzt wird, implementieren Sie Rate Limiting am ersten Tag. Das nachtraegliche Hinzufuegen bedeutet, Ihre API zu versionieren oder bestehende Clients zu beschädigen.

Die wichtigste Faehigkeit im Systemdesign ist zu wissen, was Sie nicht brauchen. Die meisten Anwendungen brauchen kein Sharding. Die meisten Anwendungen brauchen keine Message Queue. Vorzeitige Verteilung ist die Wurzel allen Uebels im Systemdesign - jedes verteilte System fuehrt Fehlermodi ein, die ein Ein-Server-System einfach nicht hat. Fuegen Sie Komplexitaet nur hinzu, wenn die Metriken es Ihnen sagen, nicht weil das Muster in einem Vorstellungsgespraech beeindruckend klingt.

Starten Sie einfach. Messen Sie alles. Fuegen Sie jeweils ein Muster hinzu. Ueberpruefen Sie die Verbesserung, bevor Sie fortfahren. Die Systeme, die ueberleben, sind nicht die mit der anspruchsvollsten Architektur - sie sind die, die leicht zu verstehen, leicht zu betreiben und leicht zu aendern sind, wenn der naechste Engpass auftritt.