Przejdź do treści
← Wróć
Architecture

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.