System-Architektur-Skizze aus Anforderung

Entwickelt aus funktionalen/nicht-funktionalen Anforderungen eine Architektur-Skizze - Komponenten, Daten-Flow, Tradeoffs, offene Fragen.

Zuletzt geprüft 23. April 2026

Prompt

Design a system architecture for the following requirements. No code yet.

Deliver:
1. COMPONENTS - each with: name, responsibility (1 sentence), inbound/outbound interfaces, data it owns
2. DATA FLOW - happy path, end-to-end, numbered steps. Call out sync vs async.
3. DATA STORES - what, why this choice (relational / document / kv / search / blob / stream). Flag any polyglot-persistence tradeoff.
4. KEY CROSS-CUTTING - auth, observability, error propagation, idempotency, backpressure, caching (only what's load-bearing)
5. NON-FUNCTIONAL FIT - how the design meets the stated NFRs. If an NFR is impossible without more info, flag it.
6. TRADEOFFS - 2-3 decisions where "we could have gone the other way", with the cost
7. OPEN QUESTIONS - what the spec doesn't answer yet

Rules:
- No brand-name soup. Abstract roles first, concrete products second (and only if asked)
- Do not invent requirements
- Diagram text OK (ASCII or mermaid), not required
- If the problem is simpler than you'd expect, say "probably doesn't need a service - a function + table would do"

Requirements:
- Functional: [WHAT IT DOES]
- Non-functional: [LOAD, LATENCY, CONSISTENCY, AVAILABILITY]
- Constraints: [TEAM, BUDGET, EXISTING STACK]
- Out of scope: [EXPLICITLY NOT]

Wann nutzen

Für den Moment, bevor Code entsteht. Zwingt Tradeoffs und offene Fragen explizit - die beiden Dinge, die in Meetings sonst verloren gehen.

Use-Cases

  • Neues Projekt, Architektur für Kickoff.
  • Feature groß genug für eigene Komponenten-Diskussion.
  • RFC-Entwurf als Diskussions-Basis.

Getestet mit

Der “probably doesn’t need a service”-Check ist wertvoll. Viele Architekturen beginnen mit zu vielen Komponenten, weil niemand die Frage gestellt hat.