Projektowanie Architektury (SDD)
Zaprojektuj spójny System Design dla nowego modułu asynchronicznego. Gotowy prompt Principal Architecta.
Dokumentacja architektury w parę minut
Stworzenie poprawnego SDD (System Design Document) to ciężkie, ale kluczowe zadanie. Dzięki temu promptowi nakierujesz model i postawisz go w centrum sprawczym głównego architekta.
Prompt
Jako wybitny ekspert w roli Principal Architect and Distinguished Engineer, opracuj kompleksową dokumentację System Design (SDD) dla nowych wymagań.
Twoim celem jest zaprojektowanie architektury gotowej na rok 2026 – bezpiecznej, skalowalnej i łatwej w utrzymaniu, w oparciu o najnowocześniejsze, ustandaryzowane wzorce.
ZASADY ANALIZY:1. Projektuj systemy rozproszone z myślą o resiliency i domyślnej asynchroniczności (Event-Driven / Choreography), chyba że z jakiegoś powodu silna spójność (consistency) jest bezwzględnie konieczna.2. Unikaj teoretyzowania – podawaj konkretne technologie, wzorce (np. Outbox, Saga, CQRS) i struktury.3. Kategorycznie ZABRANIA SIĘ pomijania analizy punktów awarii (SPOF) i wąskich gardeł.4. Przedstaw rozwiązanie w ustandaryzowanej strukturze Markdown, dokładnie według poniższego formatu.
Materiały do analizy:---WYMAGANIA BIZNESOWE I TECHNICZNE:[WKLEJ_TUTAJ_WYMAGANIA_ORAZ_KONTEKST]---
WYMAGANY FORMAT ODPOWIEDZI:
### 1. 🏗️ Executive Summary & Architektura Wysokopoziomowa* **Wizja systemu:** [2-3 zdania opisujące architekturę i główny styl architektury]* **Główne trade-offy:** [Co poświęcamy, aby zyskać - np. Eventual Consistency kosztem dostępności]* **Rekomendowany stack technologiczny:** [Główne technologie i dlaczego]
### 2. 🧩 Komponenty i Serwisy (Bounded Contexts)Rozpisz kluczowe komponenty systemu. Dla każdego zdefiniuj:* **Odpowiedzialność:** (Co robi, za co NIE odpowiada)* **Technologia bazy danych:** (SQL, NoSQL, Time-Series - uzasadnij wybór pod kątem dostępu do danych)* **Zależności:** (Czego potrzebuje do działania)
### 3. 📡 Komunikacja i Integracja (Data Flow)* **Wzorce Integracyjne:** (REST, gRPC, GraphQL, Event-Driven - Kafka/RabbitMQ)* **Schemat asynchroniczny:** (Które operacje muszą być synchroniczne, a które można oddelegować w tło)* **Gwarancje dostarczenia (Delivery Semantics):** (At-least-once, Exactly-once i jak nimi zarządzamy - np. Idempotency Keys)
### 4. 🚀 Skalowalność i Wydajność (Performance & Scale)* **Strategia Cachowania:** (Co zrzucamy do Redis/Memcached/CDN, zasady inwalidacji cache)* **Wąskie gardła (Bottlenecks):** (Gdzie system najszybciej nie wytrzyma pod obciążeniem i jak temu zapobiegać)* **High Availability (HA) & Skalowalność pozioma:** (Jakie zasoby się nie skalują, jak obsługujemy duże wolumeny i peaki trafficu)
### 5. 🛡️ Bezpieczeństwo i Compliance* **Autentykacja i Autoryzacja:** (Gdzie terminujemy sesję, kto ma dostęp do jakich API)* **Ochrona dostępu:** (WAF, Rate Limiting, DDoS protection)* **Dane Wrażliwe:** (Szyfrowanie at-rest & in-transit, maskowanie PII)
### 6. 💥 Odporność na awarie (Resiliency)* **Single Points of Failure (SPOF):** (Gdzie leży największe ryzyko)* **Polityki Retry & Fallback:** (Patterny Circuit Breaker, Timeout, Retry)* **Disaster Recovery:** (RPO/RTO i jak system radzi sobie ze śmiercią całej strefy dostępu np. Availability Zone)
### 7. 📊 Obserwowalność (Observability)* **Kluczowe metryki (Golden Signals):** (Latency, Traffic, Errors, Saturation)* **Distributed Tracing:** (Sposoby przekazywania TraceID przez cały łańcuch wywołań)Zanim zaczniesz
Do tak skonstruowanego promptu przekaż szczegółowe, precyzyjne wymagania funkcjonalne i niefunkcjonalne. Wynik tego zapytania nie jest końcem podróży – często staje się fundamentem do warsztatów z inżynierami w Twoim teamie i pretekstem do konstruktywnych sporów wokół architektury.