Software-Architektur: Die 5 Entscheidungen, die alles bestimmen

Architektur ist kein Diagramm

Software-Architektur wird oft mit Boxen und Pfeilen gleichgesetzt. Aber Architektur sind die Entscheidungen, die schwer rückgängig zu machen sind — und die den Rahmen für alles Weitere setzen.

Hier sind die fünf Entscheidungen, die den größten Einfluss auf den Erfolg eines Softwareprojekts haben.

1. Synchron oder Asynchron?

Die fundamentalste Entscheidung: Kommunizieren Ihre Komponenten synchron (Request/Response) oder asynchron (Events/Messages)?

Synchron (REST, gRPC):
– Einfacher zu verstehen und zu debuggen
– Direkte Fehlermeldung an den Aufrufer
– Enge Kopplung zwischen Sender und Empfänger

Asynchron (Kafka, RabbitMQ, SQS):
– Lose Kopplung, höhere Resilienz
– Natürliche Skalierbarkeit durch Queues
– Komplexeres Fehlerhandling, Eventual Consistency

Empfehlung: Starten Sie synchron und führen Sie Asynchronität gezielt ein, wo sie Probleme löst — nicht als Grundsatzentscheidung.

2. Datenhoheit: Shared Database oder Database per Service?

Teilen sich Ihre Services eine Datenbank — oder hat jeder Service seine eigene?

Aspekt	Shared DB	DB per Service
Konsistenz	Einfach (Transaktionen)	Komplex (Sagas)
Kopplung	Hoch (Schema-Änderungen betreffen alle)	Niedrig
Performance	Joins möglich	Kein Cross-Service-Join
Betrieb	Ein Cluster	Mehrere Cluster

Die Wahrheit: Die meisten Systeme brauchen einen Mittelweg. Logische Trennung (eigenes Schema pro Service) mit physisch geteilter Infrastruktur ist oft der pragmatische Start.

3. Deployment-Einheit: Monolith, Modulith oder Microservices?

Diese Entscheidung bestimmt Ihre gesamte Infrastruktur, CI/CD-Pipeline und Team-Organisation:

– Monolith: Ein Artefakt, einfaches Deployment, ein Team
– Modulith: Ein Artefakt mit klaren internen Grenzen, mehrere Teams möglich
– Microservices: Mehrere Artefakte, unabhängiges Deployment, Team-pro-Service

Die Entscheidung hängt weniger von der Technik ab als von der Teamgröße und -struktur (Conway’s Law).

4. Frontend-Architektur: Server-Rendered oder SPA?

Oft unterschätzt, aber schwer zu ändern:

Server-Side Rendering (Thymeleaf, JSF, HTMX):
– Weniger Komplexität, kein separater Build-Prozess
– SEO-freundlich out of the box
– Gut für content-lastige Anwendungen

Single Page Application (React, Angular, Vue):
– Reichere Interaktivität
– Eigenes Team für Frontend möglich
– API-first ermöglicht mehrere Clients (Web, Mobile)

Trend: HTMX und Server Components (React) bringen die Welten zusammen.

5. Fehlerbehandlungsstrategie

Die am häufigsten vergessene Architekturentscheidung: Was passiert, wenn etwas schiefgeht?

Definieren Sie frühzeitig:
– Circuit Breaker: Wann wird ein abhängiger Service als „down“ betrachtet?
– Retry-Strategie: Wie oft, mit welchem Backoff?
– Fallback-Verhalten: Degraded Mode oder Fehlerseite?
– Timeout-Budgets: Wie lange darf ein Request maximal dauern?

Ohne diese Entscheidungen wird Ihr System bei der ersten Störung kaskadierend ausfallen.

Architektur-Entscheidungen dokumentieren

Nutzen Sie Architecture Decision Records (ADRs) — kurze Dokumente, die festhalten:

1. Kontext: Welches Problem lösen wir?
2. Entscheidung: Was haben wir entschieden?
3. Konsequenzen: Was folgt daraus (positiv und negativ)?

# ADR-001: Asynchrone Kommunikation für Bestellprozess

Kontext
Der Bestellprozess muss 5 nachgelagerte Systeme benachrichtigen.
Synchrone Aufrufe führen zu Timeouts bei Last.

Entscheidung
Wir verwenden Apache Kafka für die Event-basierte
Kommunikation im Bestellprozess.

Konsequenzen
+ Lose Kopplung, keine kaskadierenden Fehler
+ Natürliche Skalierbarkeit
- Eventual Consistency, kein sofortiges Feedback
- Zusätzliche Infrastruktur (Kafka Cluster)

Fazit

Gute Architektur entsteht nicht durch die Wahl des richtigen Frameworks, sondern durch bewusste Entscheidungen an den richtigen Stellen. Nehmen Sie sich Zeit für diese fünf Weichenstellungen — sie bestimmen den Erfolg Ihres Projekts mehr als jede Technologiewahl.

Bei CGS IT Solutions unterstützen wir Sie als Software-Architekten bei genau diesen Entscheidungen — pragmatisch, erfahrungsbasiert und technologieneutral.