Trade-off Analysis и архитектурные решения
Нет правильных ответов — есть обоснованные решения
Главный навык System Design — не знание «правильного» решения, а умение анализировать trade-offs и выбирать подход, оптимальный для конкретных ограничений.
Каждое архитектурное решение — это компромисс:
| Хотим больше | Жертвуем |
|---|---|
| Децентрализации | Скоростью и throughput |
| Безопасности | Гибкостью и upgradability |
| Производительности | Стоимостью газа |
| Простоты контракта | Функциональностью |
| Масштабируемости | Атомарностью операций |
Framework для анализа trade-offs
1. Определить критерии оценки
Для каждого решения определите, что важно:
2. Оценить варианты
Для каждого варианта оцените по критериям (1-5):
| Критерий | Вариант A: Монолит | Вариант B: Sharded |
|---|---|---|
| Gas Cost | 4/5 (один контракт) | 2/5 (сообщения между контрактами) |
| Latency | 5/5 (без cross-shard) | 3/5 (cross-shard messages) |
| Security | 3/5 (один attack surface) | 4/5 (изоляция) |
| Scalability | 2/5 (один шард) | 5/5 (шарды параллельно) |
3. Документировать решение (ADR)
Architecture Decision Record (ADR) — стандартный формат документирования:
## ADR-001: Sharded vs Monolithic Token Contract
**Status:** Accepted
**Context:** Проектируем Jetton с ожидаемым числом холдеров 1M+
**Decision:** Sharded pattern (master + wallet contracts)
**Consequences:**
- [OK] Масштабируется до любого числа холдеров
- [OK] Параллельная обработка transfer в разных шардах
- [NO] Transfer = 3 сообщения вместо 1 (дороже в gas)
- [NO] Balance не атомарен — возможны временные несоответствияПример: Проектирование DEX — trade-off analysis
Задача: спроектировать DEX на TON. Два основных подхода:
Почему TON DEX-ы выбирают AMM
- Gas cost: Хранение orderbook на блокчейне — дорого (storage fee за каждый ордер)
- Асинхронность: Матчинг ордеров в async среде — сложно гарантировать fairness
- Простота: AMM = один контракт с формулой
x * y = k, orderbook = десятки контрактов - UX: AMM swap — одна транзакция, orderbook — создание ордера + ожидание матчинга
Правильный ответ зависит от контекста
Для low-frequency trading на дорогих активах — orderbook лучше (точные цены). Для массовых мелких swap-ов — AMM (простота и скорость). В модуле M07 мы детально разберём архитектуру обоих подходов.
Антипаттерны при принятии решений
Resume-Driven Development
Выбирать технологию, потому что она красиво смотрится в резюме, а не потому что подходит для задачи.
Premature Optimization
Оптимизировать gas для контракта с 10 пользователями, вместо того чтобы сфокусироваться на корректности.
One-Size-Fits-All
Использовать один паттерн (например, sharded) для всех контрактов, независимо от требований.
Copy-Paste Architecture
Копировать архитектуру STON.fi для своего DEX без анализа — ваши требования могут отличаться.
Чек-лист для каждого архитектурного решения
Перед фиксацией решения проверьте:
- Определены ли критерии оценки (что важно для этой конкретной системы)?
- Рассмотрены ли минимум 2 альтернативы?
- Документированы ли trade-offs каждого варианта?
- Учтены ли специфики TON (async, sharding, storage fees)?
- Есть ли план отступления, если решение окажется неверным?
- Записан ли ADR?