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.