← Alle Artikel
Zuletzt aktualisiert: 2026-03-30

Technische Architekturentscheidungen treffen, die Sie nicht bereuen

Framework für Technologieentscheidungen. Build vs Buy, Monolith vs Microservices, Datenbankauswahl.

Zusammenfassung

Architekturentscheidungen sind die teuersten Entscheidungen in der Softwareentwicklung. Eine Datenbank im Monat 18 zu wechseln kostet 10-100x mehr als im Monat 1 die richtige zu wählen. Dieser Leitfaden bietet ein strukturiertes Framework für Technologieentscheidungen: Bewerten Sie mit expliziten Kriterien, dokumentieren Sie Entscheidungen in Architecture Decision Records (ADRs) und vermeiden Sie die häufigsten Fallen — einschließlich voreiliger Microservices, lebenslaufgetriebener Entwicklung und dem Sunk-Cost-Irrtum.

Voraussetzungen

Schritt 1: Das Entscheidungsframework

Jede Architekturentscheidung sollte eine strukturierte Bewertung durchlaufen. Bauchgefühle sind keine Architektur — sie sind Glücksspiel mit dem Geld anderer Leute.

Der Fünf-Fragen-Filter

Bevor Sie eine Technologie bewerten, beantworten Sie diese Fragen:

1. Welches Problem löst das? (Konkret — "wir brauchen es" ist keine Antwort)
2. Was sind die Einschränkungen? (Team-Skills, Budget, Timeline, Compliance)
3. Was sind die Alternativen? (mindestens 3, einschließlich "nichts tun")
4. Was kostet es, falsch zu liegen? (Können wir diese Entscheidung rückgängig machen?)
5. Wann müssen wir entscheiden? (Dringlichkeit vs Wichtigkeit)

Reversibilitäts-Klassifikation

Nicht alle Entscheidungen sind gleich. Klassifizieren Sie jede Entscheidung:

Typ 1 (Einbahnstraße): Irreversibel oder extrem teuer rückgängig zu machen
  Beispiele: Programmiersprache, primäre Datenbank, Cloud-Anbieter
  Aktion:  Investieren Sie signifikant Zeit in die Bewertung. Holen Sie externes Review.

Typ 2 (Drehtür): Mit moderatem Aufwand reversibel
  Beispiele: UI-Framework, CI/CD-Tool, Monitoring-Lösung
  Aktion:  Schnelle Entscheidung treffen. Für Geschwindigkeit optimieren.

Typ 3 (Karusselltür): Trivial reversibel
  Beispiele: Code-Formatierung, Variablennamen, Ordnerstruktur
  Aktion:  Eines wählen, weitermachen. Nicht länger als 15 Minuten diskutieren.

Gewichtete Entscheidungsmatrix

Für Typ-1-Entscheidungen verwenden Sie eine gewichtete Matrix:

Kriterium (Gewicht)       | Option A  | Option B  | Option C
--------------------------+-----------+-----------+----------
Team-Expertise (25%)      |  8 (2,0)  |  5 (1,25) |  7 (1,75)
Community/Support (20%)   |  9 (1,8)  |  7 (1,4)  |  6 (1,2)
Performance (20%)         |  6 (1,2)  |  9 (1,8)  |  7 (1,4)
Betriebskosten (15%)      |  7 (1,05) |  4 (0,6)  |  8 (1,2)
Skalierbarkeit (10%)      |  7 (0,7)  |  9 (0,9)  |  7 (0,7)
Lernkurve (10%)           |  8 (0,8)  |  4 (0,4)  |  6 (0,6)
--------------------------+-----------+-----------+----------
Gesamt                    |  7,55     |  6,35     |  6,85

Die spezifischen Gewichte sind weniger wichtig als die Übung selbst. Sie zwingt Sie, zu artikulieren, was Sie wertschätzen und warum. Wenn die Ergebnisse nah beieinander liegen (innerhalb von 10%), ist die Entscheidung wahrscheinlich weniger wichtig als gedacht — wählen Sie die Option mit besserer Team-Expertise.

Schritt 2: Build vs Buy

Das ist die folgenreichste Architekturentscheidung, die die meisten Unternehmen treffen — und sie liegen konsequent in beide Richtungen falsch.

Wann kaufen (bestehenden Service/Produkt nutzen)

Wann selbst bauen

Versteckte Kosten von "Kaufen"

Sichtbare Kosten:    Lizenz-/Abogebühr
Versteckte Kosten:   - Integrationsentwicklung (oft 2-5x der geschätzten Zeit)
                     - Vendor-API-Änderungen und Breaking Updates
                     - Support-Reaktionszeiten wenn nachts etwas kaputtgeht
                     - Datenmigration bei Anbieterwechsel
                     - Feature-Requests, die nie priorisiert werden
                     - Sicherheitslücken in Code, den Sie nicht kontrollieren

Versteckte Kosten von "Bauen"

Sichtbare Kosten:    Entwicklungszeit
Versteckte Kosten:   - Laufende Wartung (planen Sie 20% der Bauzeit jährlich)
                     - Sicherheitspatches und Schwachstellenmanagement
                     - Dokumentation und Wissenstransfer
                     - On-Call-Verantwortung für das Team
                     - Opportunitätskosten — was könnte das Team sonst bauen?

Schritt 3: Monolith vs Microservices

Die am meisten überdiskutierte Architekturentscheidung der Branche. Hier ist die ehrliche Wahrheit.

Starten Sie mit einem Monolithen. Ernsthaft.

Es sei denn, Sie haben:

... sollten Sie einen Monolithen bauen. Ein gut strukturierter Monolith mit sauberen Modulgrenzen kann später aufgeteilt werden. Voreilige Microservices können nicht einfach zusammengeführt werden.

Die wahren Kosten von Microservices

Was Sie gewinnen:                  Was Sie bezahlen:
- Unabhängige Deployments           - Verteilte Systemkomplexität
- Technologievielfalt               - Netzwerklatenz zwischen Services
- Isolierte Fehlerbereiche          - Verteiltes Tracing und Debugging
- Unabhängige Skalierung            - Service Discovery und Load Balancing
                                    - Datenkonsistenz-Herausforderungen
                                    - Integrationstestkomplexität
                                    - Operativer Overhead (10-50 Services
                                      = 10-50 Dinge, die ausfallen können)

Der modulare Monolith: Der Mittelweg

Strukturieren Sie Ihren Monolithen mit klaren Modulgrenzen, wohldefinierten Schnittstellen zwischen Modulen und separaten Datenbankschemas pro Modul. Das gibt Ihnen:

# Modularer Monolith - Beispielstruktur
src/
  modules/
    users/
      api/          # Öffentliche Schnittstelle für andere Module
      internal/     # Private Implementierung
      tests/
    orders/
      api/
      internal/
      tests/
    shipping/
      api/
      internal/
      tests/
  shared/           # Nur wirklich geteilte Hilfsfunktionen
  main.py           # Composition Root

Wann Microservices tatsächlich sinnvoll sind

Wenn Sie 3+ dieser Kriterien erfüllen, können Microservices gerechtfertigt sein:

Schritt 4: Datenbankauswahl

Die Datenbank ist die am schwierigsten zu wechselnde Technologie. Wählen Sie sorgfältig.

Entscheidungsbaum

Sind Ihre Daten relational? (Entitäten mit Beziehungen)
  ├── JA → Brauchen Sie ACID-Transaktionen?
  │     ├── JA → PostgreSQL (Standardwahl für 90% der Projekte)
  │     └── NEIN → Trotzdem PostgreSQL (kann auch nicht-ACID gut)
  └── NEIN → Welche Art von Daten?
        ├── Dokumente (JSON-artig, variables Schema) → MongoDB oder PostgreSQL JSONB
        ├── Key-Value (einfache Lookups, Caching) → Redis
        ├── Zeitreihen (Metriken, IoT-Daten) → TimescaleDB oder InfluxDB
        ├── Graph (komplexe Beziehungen, Traversierungen) → Neo4j
        ├── Suche (Volltextsuche, Facetten) → Elasticsearch oder Meilisearch
        └── Wide Column (massive Skalierung, einfache Abfragen) → Cassandra/ScyllaDB

Der PostgreSQL-Standard

Wenn Sie unsicher sind, wählen Sie PostgreSQL. Es beherrscht:

Eine spezialisierte Datenbank hinzuzufügen ist eine Typ-2-Entscheidung — Sie können das später tun, wenn Sie bewiesen haben, dass Sie sie brauchen. Mit einer spezialisierten Datenbank zu starten ist eine Typ-1-Entscheidung, die Ihre gesamte Architektur einschränkt.

Multi-Datenbank-Strategie

Mehrere Datenbanken zu nutzen ist in Ordnung — aber jede muss ihre Existenz rechtfertigen:

PostgreSQL    — Primärer Datenspeicher (Source of Truth)
Redis         — Caching-Layer, Session-Storage, Rate Limiting
Elasticsearch — Volltextsuche (wenn PostgreSQL tsvector nicht reicht)

Fügen Sie KEINE Datenbank hinzu, weil:
- "MongoDB ist besser für Dokumente" (PostgreSQL JSONB reicht meist)
- "Redis ist schneller" (als was? Für welches Abfragemuster? Wie gemessen?)
- "Wir könnten es später brauchen" (YAGNI — You Aren't Gonna Need It)

Schritt 5: Architecture Decision Records (ADRs)

Jede signifikante Architekturentscheidung sollte dokumentiert werden. Nicht in einem Wiki, das niemand liest — im Code-Repository, neben dem Code, den sie betrifft.

ADR-Vorlage

# ADR-001: PostgreSQL als primäre Datenbank

## Status
Akzeptiert (2026-03-15)

## Kontext
Wir brauchen einen primären Datenspeicher für das Auftragsmanagementsystem.
Unsere Daten sind relational (Benutzer, Aufträge, Produkte mit Fremdschlüsseln).
Wir brauchen ACID-Transaktionen für die Zahlungsabwicklung.
Das Team hat 3 Entwickler mit PostgreSQL-Erfahrung, 0 mit MongoDB.

## Entscheidung
Wir verwenden PostgreSQL 16 als primäre Datenbank.

## Betrachtete Alternativen
1. MongoDB — Gut für Dokumentspeicherung, aber unsere Daten sind relational.
   Würde manuelle Transaktionsverwaltung für Zahlungen erfordern.
2. MySQL — Machbar, aber PostgreSQL hat besseren JSON-Support,
   den wir für flexible Produktattribute brauchen.
3. CockroachDB — Verteiltes PostgreSQL-kompatibel, aber wir brauchen
   noch kein Multi-Region und es erhöht die operative Komplexität.

## Konsequenzen
- Wir bekommen ACID-Transaktionen out of the box
- Wir können JSONB für flexible Schemas nutzen wo nötig
- Wir müssen Connection Pooling verwalten (PgBouncer)
- Wir akzeptieren Single-Region-Deployment vorerst
- Bei Multi-Region-Bedarf können wir zu CockroachDB migrieren

## Review-Datum
2026-09-15 (6 Monate)

Wo ADRs speichern

project-root/
  docs/
    adr/
      0001-postgresql-nutzen.md
      0002-modularer-monolith.md
      0003-stripe-fuer-zahlungen.md
      template.md

Wann ein ADR schreiben

Problembehandlung & Hinweise

"Wir haben bereits die falsche Wahl getroffen"

Quantifizieren Sie zuerst die Kosten des Weitermachens vs die Kosten des Wechselns. Meistens sind die Wechselkosten höher als geschätzt und der Nutzen geringer. Wenn Sie sich zum Wechsel entscheiden, tun Sie es inkrementell: Strangler-Fig-Pattern für Services, Dual-Write für Datenbanken, Feature Flags für Frameworks.

"Das Team will [neue glänzende Technologie] nutzen"

Fragen Sie: "Welches Problem löst das, das unser aktueller Stack nicht löst?" Wenn die Antwort "es ist moderner" oder "das nutzen alle" ist, widersprechen Sie. Lebenslaufgetriebene Entwicklung ist eines der teuersten Muster unserer Branche. Neue Technologie ist in Ordnung, wenn sie ein echtes Problem löst — aber sie muss gegen das Framework bewertet werden, nicht aus Begeisterung adoptiert.

"Stakeholder wollen eine technologiespezifische Lösung"

Nicht-technische Stakeholder fordern manchmal bestimmte Technologien an ("bau es auf Blockchain", "nutze KI dafür"). Übersetzen Sie zurück zum Problem: "Welches Ergebnis möchten Sie?" Oft ist das Problem besser mit bewährter, einfacherer Technologie lösbar.

"Wir haben keine Zeit für ordentliche Bewertung"

Eine Typ-1-Entscheidung, die in 2 Stunden getroffen wird, kostet Sie 200 Stunden zur Korrektur. Blockieren Sie den Kalender. Machen Sie die Bewertung. Die 2 Tage, die Sie jetzt investieren, sparen 2 Monate später.

Prävention & Best Practices

Der Technology Radar

Pflegen Sie einen Team-Technology-Radar mit vier Ringen: Adopt (in Produktion nutzen), Trial (in nicht-kritischen Projekten nutzen), Assess (in Spikes evaluieren), Hold (nicht nutzen). Vierteljährlich reviewen. Das verhindert sowohl leichtsinnige Adoption als auch Stagnation.

Proof of Concept vor der Festlegung

Für jede Typ-1-Entscheidung bauen Sie einen zeitlich begrenzten Proof of Concept (maximal 1-2 Wochen). Fokussieren Sie auf den riskantesten Aspekt — nicht den Happy Path. Wenn Sie eine Datenbank evaluieren, testen Sie Fehlerszenarien, Backup/Restore und Migrationswerkzeuge, nicht nur einfache CRUD-Operationen.

Architektur-Reviews

Planen Sie vierteljährliche Architektur-Reviews. Schauen Sie ADRs an, prüfen Sie deren Konsequenzen-Abschnitt und fragen Sie: Hat die Realität unsere Vorhersage bestätigt? Aktualisieren oder ersetzen Sie ADRs, die sich als falsch herausgestellt haben.

Die "Langweilige Technologie"-Regel

Dan McKinleys Essay "Choose Boring Technology" sollte Pflichtlektüre sein. Sie haben eine begrenzte Anzahl von "Innovations-Token" — nutzen Sie sie für Ihr Kernprodukt, nicht für Ihre Datenbank, Deployment-Pipeline oder Ihren Monitoring-Stack.

Notausgänge

Wenn Sie eine Typ-1-Entscheidung treffen, designen Sie immer einen Notausgang. Nutzen Sie ein ORM, damit Sie Datenbanken wechseln können. Nutzen Sie eine Message-Queue-Abstraktion, damit Sie Implementierungen tauschen können. Nutzen Sie Infrastructure-as-Code, damit Sie Cloud-Anbieter wechseln können. Der Notausgang kostet vielleicht 10% mehr im Voraus, spart aber das 10-fache, wenn Sie ihn brauchen.

Experten-Hilfe gebraucht?

Expertenmeinung zu Ihrer Architektur? €250.

Jetzt buchen — €250

100% Geld-zurück-Garantie

HR

Harald Roessler

Infrastructure Engineer mit 20+ Jahren Erfahrung. Gründer der DSNCON GmbH.

Verwandte Artikel

Bevor Sie ein KI-Produkt bauen: Die Architektur-Fragen, die niemand stellt €200 Ist Ihre Infrastruktur ein Risiko? Hosting, CI/CD und Monitoring bewerten €250 Software-Anforderungen schreiben, die Entwickler tatsächlich umsetzen können €150