System Design Interview Guide 2026: Frameworks, Muster und Fallstudien

Systemdesign-Vorstellungsgespräche sind der Schlüssel zu leitenden Ingenieurspositionen bei führenden Technologieunternehmen. Sie testen Ihre Fähigkeit, skalierbare, zuverlässige Systeme unter unklaren Anforderungen zu entwerfen. Dieser Leitfaden behandelt die Frameworks, Muster und realen Beispiele, die Sie benötigen, um sie im Jahr 2026 zu meistern.

Der Interviewrahmen

Jedes Systemdesign-Interview folgt einer ähnlichen Struktur. Nutzen Sie diesen 45-Minuten-Rahmen:

• 1-5 Min— Anforderungen klären, Umfang definieren
• 5-10 Min— Geschätzter Umfang (Benutzer, QPS, Speicher)
• 10-20 Min— Hochwertiges Design, Kernkomponenten
• 20-35 Min— Tiefer Einblick in kritische Komponenten
• 35-45 Min— Größenordnung, Engpässe, Kompromisse

Schritt 1: Anforderungen klären

Beginnen Sie niemals mit dem Entwerfen, bevor Sie diese Fragen gestellt haben:

• Wer sind die Benutzer? Was müssen sie tun?
• Was sind die Kernfunktionen im Vergleich zu „Nice-to-have“-Funktionen?
• Wie viele Benutzer? Leselastig oder Schreiblastig?
• Wie hoch ist die erforderliche Latenz? Was ist die Konsistenzanforderung?
• Wie hoch ist das erwartete Datenvolumen? Wie lange werden die Daten aufbewahrt?

Schritt 2: Kapazitätsschätzung

Grobe Mathematik, die Ingenieursreife signalisiert:

Example: Design Twitter-like feed

Users: 500M total, 100M daily active (DAU)
Tweets: 100M DAU × 5 tweets/day = 500M tweets/day
Reads: 100M DAU × 100 timeline views/day = 10B reads/day

QPS (writes): 500M / 86400 ≈ 5,800 tweets/sec (peak 3x = 17,000)
QPS (reads): 10B / 86400 ≈ 115,000 reads/sec (peak 3x = 345,000)

Storage (tweets):
- 500M tweets/day × 280 bytes = 140 GB/day
- 5 years = 140 × 365 × 5 ≈ 255 TB of tweet data

Media storage: 10% of tweets have images (100MB avg)
50M tweets/day × 100KB thumbnail = 5 TB/day thumbnail storage

Kernentwurfsmuster

1. Datenbankauswahl

Wählen Sie die richtige Datenbank für den Job:

• Relational (PostgreSQL, MySQL)— ACID-Transaktionen, komplexe Abfragen, Finanzdaten
• Dokument (MongoDB)– flexibles Schema, verschachtelte Daten, Inhaltsverwaltung
• Schlüsselwert (Redis, DynamoDB)– Caching, Sitzungsspeicherung, O(1)-Suchen
• Breite Spalte (Cassandra, HBase)– Zeitreihen, schreibintensiv in großem Maßstab
• Diagramm (Neo4j)– soziale Diagramme, Empfehlungsmaschinen
• Suche (Elasticsearch)— Volltextsuche, Protokollanalyse

2. Caching-Strategie

Cache-Aside (Lazy Loading):
  App → cache miss → DB → write to cache → return

Write-Through:
  App → write to cache AND DB simultaneously

Write-Back (Write-Behind):
  App → write to cache → async write to DB (faster, risk data loss)

Read-Through:
  Cache handles DB fetching automatically (used by Redis+Memcached)

Cache Eviction Policies:
  LRU  — Least Recently Used (most common)
  LFU  — Least Frequently Used
  TTL  — Time-To-Live expiry

3. Lastausgleich

Verteilen Sie den Datenverkehr auf mehrere Server:

• Round Robin— Gleichverteilung, einfach
• Geringste Verbindungen– Route zum Server mit den wenigsten aktiven Verbindungen
• IP-Hash– Sticky-Sitzungen basierend auf der Client-IP
• Gewichtet– Verteilung basierend auf der Serverkapazität

Tools: AWS ALB, Nginx, HAProxy, Envoy, Cloudflare

4. Datenbankskalierung

Vertical Scaling: Bigger machine (CPU, RAM, SSD)
  Pros: Simple, no code changes
  Cons: Limits, single point of failure, expensive

Read Replicas: Primary handles writes, replicas handle reads
  Pros: Read scalability, disaster recovery
  Cons: Replication lag (eventual consistency)

Sharding (Horizontal Partitioning):
  Split data across multiple DBs by key

  Hash-based: shard = hash(user_id) % num_shards
    Pros: Even distribution
    Cons: Hard to add shards (resharding)

  Range-based: shard by date range or ID range
    Pros: Range queries efficient, easy to add new shards
    Cons: Hot spots (most recent shard gets all writes)

  Directory-based: lookup table maps keys to shards
    Pros: Flexible
    Cons: Lookup overhead, single point of failure

Fallstudie: Design-URL-Shortener (bit.ly)

Anforderungen

Funktional: URL kürzen, bei Besuch umleiten, benutzerdefinierte Aliase, Ablaufdatum
Nicht funktionsfähig: 100 ms Leselatenz, 100 Millionen URLs/Tag Schreibvorgänge, 10 Milliarden Lesevorgänge/Tag

Skalenschätzung

Schreibvorgänge: 100 Mio./Tag = 1.200 QPS (Spitze 3.600)
Lesevorgänge: 10 B/Tag = 115.000 QPS (Spitze 345.000) –leselastig 100:1
Speicher: 100 MB × 500 Byte = 50 GB/Tag × 5 Jahre = ~90 TB

Hochwertiges Design

Client → Load Balancer → Web Servers → Cache (Redis)
                                          ↓ cache miss
                                       Database (PostgreSQL + replicas)

URL Shortening API:
  POST /api/shorten
  { "url": "https://very-long-url.com/path", "alias": "mylink", "expires_at": "2027-01-01" }
  → { "short_url": "https://bit.ly/abc123" }

Redirect API:
  GET /{short_code}
  → 301/302 redirect to original URL

Key Generation:
  Option 1: Base62 hash of MD5(url) — take first 7 chars
  Option 2: Counter + Base62 encode (guaranteed unique)
  Option 3: Pre-generate keys in KGS (Key Generation Service)

Datenbankschema

CREATE TABLE urls (
  id           BIGSERIAL PRIMARY KEY,
  short_code   VARCHAR(10) UNIQUE NOT NULL,
  original_url TEXT NOT NULL,
  user_id      BIGINT,
  created_at   TIMESTAMP DEFAULT NOW(),
  expires_at   TIMESTAMP,
  click_count  BIGINT DEFAULT 0
);

CREATE INDEX idx_short_code ON urls(short_code);
CREATE INDEX idx_user_id ON urls(user_id);

Fallstudie: Entwerfen Sie ein Chat-System (WhatsApp)

Wichtigste Herausforderungen

• Lieferung in Echtzeit– WebSockets für dauerhafte Verbindungen
• Reihenfolge der Nachrichten— Sequenznummern pro Gespräch
• Offline-Lieferung– Speichern Sie Nachrichten, bis der Benutzer die Verbindung wiederherstellt
• Quittungen lesen– Status „Zugestellt/gelesen“.
• Gruppenchat— Auffächerung an mehrere Benutzer

Architecture:

Client ←→ WebSocket Gateway (stateful) ←→ Message Service
                                              ↓
                                    Message Queue (Kafka)
                                              ↓
                                    Message Store (Cassandra)
                                    - Partitioned by conversation_id
                                    - Ordered by timestamp within partition

Message Flow:
1. User A sends message → WebSocket Gateway (Server A)
2. Gateway publishes to Kafka topic
3. Message Service writes to Cassandra
4. User B's WebSocket Gateway subscribes and delivers
5. If User B offline → push notification via FCM/APNs

Schema (Cassandra - wide column):
  messages_by_conversation
    conversation_id (partition key)
    message_id (clustering key, time-ordered)
    sender_id, content, message_type, created_at

Wichtige Kompromisse, die Sie kennen sollten

• SQL vs. NoSQL– ACID vs. Skalierung, Schema vs. Flexibilität
• Konsistenz vs. Verfügbarkeit— CAP-Theorem (bevorzugen Sie AP für Soziales, CP für Banking)
• Ziehen vs. Drücken– Fan-Out beim Lesen vs. Fan-Out beim Schreiben für Feeds
• Monolith vs. Microservices– Einfachheit vs. Skalierbarkeit/Teamautonomie
• Synchron vs. Asynchron– Latenz vs. Durchsatz/Ausfallsicherheit
• Starke vs. letztendliche Konsistenz— Korrektheit vs. Verfügbarkeit

Allgemeine Systemdesign-Themen (2026)

1. URL-Shortener
2. Twitter/Social Feed
3. WhatsApp/Messenger
4. Instagram/Foto-Sharing
5. YouTube/Video-Streaming
6. Uber/Mitfahrgelegenheit
7. Airbnb/Buchungssystem
8. Google-Suche
9. Ratenbegrenzer
10. Verteilter Cache (Redis)
11. Benachrichtigungssystem
12. Webcrawler
13. Metriken/Überwachung (Prometheus)
14. Verteilte Nachrichtenwarteschlange (Kafka)

Systemdesign-Interviews belohnen klare Kommunikation, strukturiertes Denken und das Bewusstsein für Kompromisse gegenüber perfekten Antworten. Üben Sie jede Woche, zwei bis drei Systeme von Grund auf zu entwerfen, und stellen Sie immer klärende Fragen, bevor Sie eine einzelne Box zeichnen.