E-01 · Бронирование билетов — вход#
Этап прогона: 5 из 6 пройдено · вход зафиксирован 2026-09-16 Кейс: CASE-08 бронирование билетов · платёжная часть — CASE-09 Шаги: W0 · Рамки и требования и W1 · Оценки на салфетке
Зачем этот прогон. Все документы решений содержат оговорку «пример условный, числа выдуманы». Ни один ещё не заполнялся по-настоящему, и стыки между ними — поля ADR, словари пометок, нумерация — согласованы только потому, что их так написали. Прогон одного кейса через всю цепочку проверяет то, чего не проверяет ни один документ по отдельности.
Система вымышлена, но внутренне непротиворечива. Числа не взяты у реальной компании; они выбраны так, чтобы арифметика сходилась и решения принимались на них по-настоящему. Каждое помечено:
[продукт]— задано заказчиком,[расчёт]— выведено на этом шаге,[допущение]— принято нами, требует проверки замером.
План прогона#
| Этап | Что делаем | Документ | Статус |
|---|---|---|---|
| 1 | Вход: рамки, числа, инварианты | W0, W1 | ✅ этот файл |
| 2 | Выбор хранилища | D-01 → ADR-0001 | ✅ |
| 3 | Границы сервисов | D-02 → ADR-0002 | ✅ |
| 4 | Связь в процессе «резерв → оплата» | D-04 → ADR-0003 | ✅ |
| 5 | Стратегия кэширования схемы зала | D-03 → ADR-0004 | ✅ |
| 6 | Ревизия прогона: что вскрылось, правки в шаблоны | план | ◐ план готов, ждёт решений |
Порядок — по шагам workflow (W3 → W4 → W6 → W5), а не по номерам документов. Если порядок окажется неверным, это находка шестого этапа, а не повод менять его сейчас.
1. Что строим#
Площадка продажи билетов на события: концерты, спорт, театр. Организатор заводит событие и схему зала, покупатель выбирает место, резервирует его и оплачивает.
Вне рамок — записано явно, чтобы не расползалось:
- динамическое ценообразование;
- перепродажа билетов между пользователями;
- автоматическая рассадка групп рядом;
- мобильные приложения — только веб;
- мультивалютность и международные платежи.
2. Инварианты#
Главное, что отличает этот кейс от большинства: дефицитный ресурс, за который идёт настоящая конкуренция.
| № | Инвариант | Чем грозит нарушение |
|---|---|---|
| И1 | У одного места не более одного действующего резерва или билета | Двое приходят на одно место — репутационный и юридический ущерб |
| И2 | Оплаченный билет не аннулируется автоматически ни при каких таймаутах | Списали деньги, места нет |
| И3 | За одну попытку оплаты деньги списываются не более одного раза | Двойное списание; разбор вручную |
| И4 | Освобождение истёкшего резерва идемпотентно | Повторное освобождение отнимает место у того, кто его уже занял |
И1 и И3 — жёсткие: следуют из обязательств перед покупателем, а не из удобства. И2 и И4 — свойства реализации, но нарушение видно пользователю.
3. Профиль нагрузки#
Определяющее число этого кейса — не объём, а неравномерность.
| Показатель | Значение | Откуда |
|---|---|---|
| Билетов продаётся | 500 тыс. в месяц | [продукт] |
| Просмотров схемы зала на одну покупку | ~40 | [допущение] — проверяется логами |
| Средняя нагрузка на чтение | ≈ 8 запросов/с | [расчёт]: 500 тыс. × 40 ÷ (30 × 86 400) |
| Старт продаж крупного события | 40 тыс. человек в первую минуту на 10 тыс. мест | [продукт] |
| Обновление схемы зала клиентом | раз в 5 с, пока человек выбирает | [допущение] |
| Пик на чтение | ≈ 8 000 запросов/с | [расчёт]: 40 тыс. × 12 обновлений ÷ 60 с |
| Пик на запись (попытки резерва) | ≈ 300 в секунду | [расчёт]: 40 тыс. × 2 попытки ÷ 5 мин |
| Коэффициент пика | ≈ 1000× | [расчёт]: 8 000 ÷ 8 |
Коэффициент пика в тысячу раз — это и есть предмет проектирования. W1 называет типичный диапазон 3–10, для событийных систем до 100; здесь на порядок больше, потому что продажи на событие открываются в назначенную минуту и вся аудитория приходит одновременно.
Конкуренция за строку. 40 тыс. человек на 10 тыс. мест — примерно четыре претендента на место, и они борются за одни и те же популярные ряды. Конфликт при резерве — норма, а не исключение.
4. Объём данных#
| Сущность | Размер записи | В год | Откуда |
|---|---|---|---|
| Билет | ~500 Б | 6 млн записей, 3 ГБ | [расчёт]: 500 тыс./мес × 12 |
| Резервы, включая истёкшие | ~300 Б | 18 млн записей, 5 ГБ | [допущение]: три попытки на проданный билет |
| История статусов и аудит | ~200 Б | 24 млн записей, 5 ГБ | [допущение] |
| Итого с индексами (×2) | ≈ 26 ГБ в год | [расчёт] |
|
| Срок хранения | 5 лет | ≈ 130 ГБ | [продукт] — требование бухгалтерии |
Это ничтожно. 130 ГБ за пять лет помещается на один узел с запасом, и никакого шардирования здесь не потребуется ни при каком реалистичном росте. Узкое место этой системы — конкуренция за строки в момент пика, а не объём и не общая пропускная способность. Оценка на салфетке нужна была ровно чтобы это показать: без неё естественно начать проектировать распределённое хранилище под задачу, которая его не требует.
5. Бюджет задержки#
Целевой p99 на резерв места — 300 мс [продукт]: дольше, и пользователь жмёт кнопку второй раз, добавляя нагрузку в худший момент.
| Участок | Бюджет |
|---|---|
| Сеть до площадки и обратно | 40 мс |
| Периметр и маршрутизация | 10 мс |
| Сервис | 20 мс |
| Запись в БД с блокировкой строки | 60 мс |
| Сериализация и прочее | 10 мс |
| Сумма | 140 мс |
Запас двукратный — он весь уйдёт в очередь на популярных местах, где конфликтующие транзакции выстраиваются друг за другом. Чтение схемы зала: p99 200 мс [продукт].
6. Доступность#
| Режим | Цель | Цена простоя |
|---|---|---|
| Обычное время | 99.9 % | Упущенные продажи, распределены равномерно |
| Окно старта продаж | близко к 100 % | Выручка события целиком: старт не повторяют |
Доступность здесь неравномерна во времени — полчаса в неделю стоят дороже, чем остальные 167 часов вместе. Это не выражается одним числом девяток, и все решения ниже принимаются под окно старта, а не под среднюю нагрузку.
7. Ограничения, не относящиеся к технике#
Они станут дисквалификаторами, поэтому фиксируются здесь, а не всплывают на середине сравнения.
- Команда: четыре разработчика, отдельной платформенной команды нет, дежурство по очереди
[продукт]. - Размещение: один облачный провайдер, две зоны доступности в одном регионе; второго региона нет и не планируется в горизонте года
[продукт]. - Персональные данные покупателей — имя, телефон, почта — хранятся в юрисдикции, где работает компания
[продукт]. - Платежи — через внешнего провайдера; собственной платёжной лицензии нет
[продукт]. - Опыт команды: реляционные БД — да; Kafka, Kubernetes, движки оркестрации — нет
[продукт].
8. Что осталось неизвестным#
Записано намеренно: в документах решений эти места дадут [нет данных], и видно будет, какие из них блокируют решение, а какие нет.
| Неизвестно | Чем закроется |
|---|---|
| Реальное соотношение чтений к записям | Логи запросов за месяц после запуска |
| Фактическое время от резерва до оплаты | Замер; определяет срок резерва |
| Доля отказов «место только что заняли» | Замер на первом крупном старте |
| Стоимость исходящего трафика на схемах зала | Тариф провайдера и замер размера ответа |
Дальше: этап 6 — план ревизии.