Приведи пример самого сложного технического задания

Пример самого сложного технического задания

За 10+ лет я работал над множеством проектов разной сложности. Сейчас поделюсь примером одного из наиболее сложных ТЗ, которое я создавал — система реального времени для финансовой торговли. Это показывает, какие вызовы возникают при проектировании высоконагруженных систем.

Проект: Real-Time Trading Platform

Контекст и вызовы

Бизнес-контекст: Финтех компания разрабатывает платформу для розничных инвесторов, которые хотят торговать акциями и криптовалютами в реальном времени. Конкурируют с Robinhood, Interactive Brokers.

Основной вызов: Система должна обрабатывать:

• 10,000+ одновременных пользователей
• 100,000+ операций в секунду (orders per second)
• Задержка менее 100мс от клиента до исполнения
• 99.99% uptime (максимум 52 минут downtime в год)
• Регуляторные требования (KYC, AML, compliance)

Часть 1: Функциональные требования

FR-001: Real-Time Quote Streaming

Система должна потреблять котировки акций из множества источников и распространять их пользователям в реальном времени.

Требования:

• Источники данных: Bloomberg, IEX Cloud, Coinbase, Binance
• Обновление котировок каждые 100мс для акций
• Задержка распределения менее 50мс
• Поддержка до 100,000 подписок одновременно
• При недоступности источника переключиться на backup
• Кэширование последних 24 часов котировок

FR-002: Order Management System (OMS)

Управление заказами от создания до исполнения.

Поддерживаемые типы:

• Market Order (исполнить по текущей цене)
• Limit Order (исполнить если цена в диапазоне)
• Stop Loss (активируется при падении цены)
• Take Profit (активируется при росте цены)
• Trailing Stop (следит за максимальной ценой)

Требования:

• Время от создания до исполнения: менее 100мс
• Поддержка частичного исполнения
• Гарантия FIFO при одной цене
• Atomicity (либо полностью исполнен, либо отклонен)

FR-003: Matching Engine

Ядро системы — матчинг покупателей и продавцов.

Требования:

• Алгоритм Price-Time Priority matching
• Обработка 100,000 заказов в секунду
• Полная аудит-история всех заказов
• Поддержка частичного матчинга
• При одинаковом времени: первый пришедший исполняется первым

FR-004: Risk Management

Контроль рисков на уровне пользователя и платформы.

Уровень пользователя:

• Maximum position: максимум 10% портфеля на инструмент
• Maximum daily loss: не более 5% капитала
• Leverage limit: максимум 3x для розничных
• Concentration limit: не более 20% на сектор

Уровень платформы:

• Circuit breaker: пауза при волатильности выше 20%
• Maximum daily volume: не более 50M акций в день
• Стресс-тестирование при нагрузке 5x выше нормы

Часть 2: Нефункциональные требования

NFR-001: Performance

• P99 latency для создания заказа: менее 50мс
• P99 latency для получения котировки: менее 20мс
• Throughput: минимум 100,000 операций в секунду
• Database query time: менее 5мс для 99% запросов
• Cache hit rate выше 95% для популярных инструментов
• Support 10,000+ одновременных соединений

NFR-002: Reliability

• Uptime: 99.99% SLA
• Recovery Time Objective: менее 5 минут
• Recovery Point Objective: менее 1 минуты
• Replication: 3+ копии данных на разных дата-центрах
• Automatic failover менее чем за 10 секунд
• Data consistency: все операции сохраняются

NFR-003: Security

• Двухфакторная аутентификация
• Role-Based Access Control для авторизации
• TLS 1.3 для всех соединений
• AES-256 для зашифрованных данных
• Rate limiting: 100 запросов в секунду на IP
• PCI-DSS compliance для платежей
• Аудит-логирование всех финансовых операций
• Квартальное тестирование безопасности
• ISO 27001 compliance

NFR-004: Scalability

• Горизонтальное масштабирование без downtime
• Stateless архитектура фронтенда
• Load balancing с распределением по shard'ам
• Database sharding по user ID
• Message queue для асинхронной обработки
• Система справляется с пиком 5x обычной нагрузки

Почему это сложное ТЗ

Множество зависимостей: Quote provider, payment system, compliance, regulatory bodies. Изменение в одной части может сломать другую часть системы.

Противоречивые требования:

• Низкая задержка VS надежное хранение
• Высокая пропускная способность VS минимальная задержка
• Быстрота VS безопасность

Неопределенность:

• Как обрабатывать race conditions при одновременных заказах?
• Что если Quote provider упадет во время matching?
• Как справиться с regulatory changes?

Техническая сложность:

• Распределенные системы с множеством микросервисов
• Real-time processing потоковых данных
• High throughput с low latency требованиями
• Complex matching алгоритм

Организационная сложность:

• Координация между множеством команд
• Финансовые регуляции (юристы, compliance-офицеры)
• Критичность: потеря денег = судебные дела

Как я структурирую такое ТЗ

1. Overview — цель, рынок, timeline, budget
2. Functional Requirements — что система делает
3. Non-Functional Requirements — производительность, надежность, безопасность
4. Data Models — структура данных
5. API Specifications — endpoints и behavior
6. Data Flow Diagrams — как данные течут
7. Error Handling — обработка ошибок
8. Regulatory Compliance — соответствие законам
9. Testing Strategy — стратегия тестирования
10. Deployment and Operations — деплоймент и поддержка

Ключевые вызовы при анализе

Выявление конфликтов: Требование быстрого ответа (менее 100мс) конфликтует с надежностью. Решение: асинхронная обработка через очередь сообщений.

Управление неопределенностью: Что если два заказа придут одновременно? Решение: использовать server-side timestamp, а не клиентский.

Регуляторное соответствие: Финансовые системы имеют жесткие требования. Нужна работа с compliance officer.

Масштабируемость: Как система справится со стократным ростом пользователей? Планирование заранее критично.

Вывод

Сложное ТЗ требует глубокого понимания домена, способности видеть взаимозависимости, умения разрешать конфликты и четкого документирования. Такие проекты научили меня, что системный анализ это не просто сбор требований, а архитектурное мышление высокого уровня.