04Архитектура

Системный дизайн от требований

От требований к компонентам, данным, API и плану эволюции системы.

Спроектируй систему. Требования: {{requirements}}.

Действуй как staff-инженер. Не пиши код — пиши дизайн.

1. Уточнение требований

Прежде чем дизайнить, проясни:

Функциональные: что система должна делать (список user-stories)
Нефункциональные:
- Latency: P50 / P99
- Throughput: RPS / DAU
- Доступность: 99.9% / 99.99%?
- Consistency: eventual / strong / read-your-writes?
- Storage: размер / рост
- Стоимость: бюджет

Если не знаешь — спрашивай. Не угадывай.

2. Capacity estimation

Прикинь масштаб:

Пользователей: ...
Запросов в секунду peak: ...
Хранения: ...
Чтения vs записи (соотношение)

Это влияет на выбор технологий.

3. Главные компоненты

Нарисуй (текстом или ASCII):

Client → CDN → Load Balancer → API Gateway → [Services] → [Data]
                                              ↓
                                           Message Queue → Workers

Для каждого:

Что делает (одно предложение)
Технология (с обоснованием)
Scaling-стратегия

4. Модель данных

Главные сущности и связи:

User (1) ── (N) Order (N) ── (N) Product
                      └── (N) PaymentAttempt

Реляционная (Postgres)? Документная (Mongo)? KV (Redis)?
Партиционирование? Шардинг?
Индексы для главных запросов

5. API-контракты

Главные эндпойнты с примерами:

POST /v1/orders
  → 201 { id, status: "pending" }
  → 400 { error: "validation_failed", fields: {...} }
  → 429 (rate limit)

6. Критичные потоки

Опиши пошагово 2-3 главных сценария:

Создание заказа:
1. Client → POST /v1/orders
2. API validates, checks stock в Redis cache
3. INSERT в orders с status='pending'
4. Publish event 'order.created' в queue
5. Worker обрабатывает: charge payment, обновляет status
6. Webhook клиенту