Monolith

Einfach erklärt

Ein Monolith ist eine Software-Anwendung, bei der alles zusammen in einer Codebasis lebt und als eine Einheit deployed wird. Frontend, Backend, Datenbank-Zugriff – alles in einem Paket.

Monolith vs. Microservices:

Monolith:
┌─────────────────────────────────┐
│         Eine Anwendung          │
│  ┌─────┐ ┌─────┐ ┌─────┐       │
│  │User │ │Order│ │Pay- │       │
│  │Modul│ │Modul│ │ment │       │
│  └─────┘ └─────┘ └─────┘       │
│         Eine Datenbank          │
└─────────────────────────────────┘

Microservices:
┌─────┐   ┌─────┐   ┌─────┐
│User │   │Order│   │Pay- │
│Svc  │   │Svc  │   │ment │
│ DB  │   │ DB  │   │ DB  │
└─────┘   └─────┘   └─────┘
    ↕         ↕         ↕
        API Gateway

Vorteile des Monolithen:

Vorteil	Erklärung
Einfachheit	Eine Codebasis, ein Deployment, ein Debugging
Schneller Start	Kein Overhead für Service-Kommunikation
Einfaches Testing	Alles in einem Prozess testbar
Keine Netzwerk-Latenz	Funktionsaufrufe statt API-Calls

Nachteile bei Wachstum:

Nachteil	Erklärung
Deployment-Risiko	Kleine Änderung = ganzes System neu deployen
Skalierung	Alles oder nichts skalieren
Team-Blockaden	Alle arbeiten in derselben Codebasis
Tech-Stack-Lock-in	Eine Sprache/Framework für alles

Technischer Deep Dive

Monolith-Struktur

Typische Schichten:

┌─────────────────────────────────┐
│       Presentation Layer        │
│     (UI, API Controllers)       │
├─────────────────────────────────┤
│       Business Logic Layer      │
│     (Services, Use Cases)       │
├─────────────────────────────────┤
│       Data Access Layer         │
│     (Repositories, ORM)         │
├─────────────────────────────────┤
│          Database               │
└─────────────────────────────────┘

Modular Monolith

Der Kompromiss zwischen Monolith und Microservices:

┌─────────────────────────────────┐
│         Monolith                │
│  ┌─────────┐ ┌─────────┐       │
│  │ User    │ │ Order   │       │
│  │ Module  │ │ Module  │       │
│  │ ─────── │ │ ─────── │       │
│  │ Public  │ │ Public  │       │
│  │ API     │←→│ API     │       │
│  │ ─────── │ │ ─────── │       │
│  │ Private │ │ Private │       │
│  │ Impl    │ │ Impl    │       │
│  └─────────┘ └─────────┘       │
└─────────────────────────────────┘

Regeln:

• Module kommunizieren nur über definierte APIs
• Keine direkten Datenbank-Zugriffe zwischen Modulen
• Klare Ownership pro Modul
• Später einfacher in Microservices extrahierbar

Wann Monolith, wann Microservices?

Kriterium	Monolith	Microservices
Team-Größe	< 10 Entwickler	> 20 Entwickler
Deployment-Frequenz	Wöchentlich	Täglich/stündlich
Skalierung	Gleichmäßig	Unterschiedlich pro Service
Domain-Komplexität	Einfach-mittel	Hoch, viele Bounded Contexts
Ops-Expertise	Begrenzt	Stark (K8s, Observability)

Monolith skalieren

Horizontal:

Load Balancer
     │
     ├── Monolith Instance 1
     ├── Monolith Instance 2
     └── Monolith Instance 3
           │
      Shared Database

Optimierungen:

• Caching (Redis)
• Read Replicas für DB
• CDN für statische Assets
• Async Processing (Message Queue)

Migration zu Microservices

Strangler Fig Pattern:

1. Neue Features als Services bauen
2. Bestehende Features schrittweise extrahieren
3. Monolith wird kleiner, bis er verschwindet

Phase 1:        Phase 2:        Phase 3:
┌────────┐     ┌────────┐      ┌─────┐
│Monolith│     │Mono-   │      │Svc A│
│        │     │lith    │      └─────┘
│        │     ├────────┤      ┌─────┐
│        │     │ Svc A  │      │Svc B│
└────────┘     └────────┘      └─────┘