---
title: Материал 25 — Architectural Katas (architecturalkatas.com + nealford.com/katas): банк брифов для тренировочных раундов
source_1: https://www.architecturalkatas.com/ (Ted Neward; сами каты — JSON в GitHub-репо tedneward/ArchKatas, 38 шт.)
source_2: https://nealford.com/katas/ (Neal Ford; зеркало оригинала, кураторский список из 20 кат с явным полем users)
конспект: подготовлено 2026-09-18, TASK-45.29; тексты кат скачаны из репо и сверены с обеими витринами; выбраны 3 каты под наш формат + резерв
статус: источник незнакомых брифов для раундов на доске: тренируют этап 1 (требования на незнакомом домене) — то, чего не дают эталонные разборы classic-designs; протокол использования — `../methodology.md` §6.5
---

# Материал 25: Architectural Katas — тренировка на незнакомых брифах

Ката = короткий бриф «заказчик хочет систему X» без подсказок: нет эталонного решения, нет готового масштаба, требований перечислено ровно столько, сколько дал заказчик. Это ближайший к реальной секции формат тренировки: на интервью тоже дают незнакомый бриф и смотрят, как ты сам выспрашиваешь масштаб, режешь скоуп и защищаешь трейдоффы.

## 1. Два сборника и что из них брать

| Сборник | Что это | Объём | Особенность |
|---|---|---|---|
| [architecturalkatas.com](https://www.architecturalkatas.com/) | Оригинал Ted Neward (2012 → живой проект); каты лежат JSON-файлами в GitHub-репо [tedneward/ArchKatas](https://github.com/tedneward/ArchKatas) | 38 кат | Самый свежий и полный банк; формат брифа: сценарий → Users → Requirements → Additional Context; кнопки «random» и «all» на сайте |
| [nealford.com/katas](https://nealford.com/katas/) | Зеркало от Neal Ford («inspired by Ted Neward's original») | 20 кат | Подмножество старого списка, но у каждой каты масштаб вынесен в отдельное поле `users` — удобно для быстрых прикидок; у части кат другой набор контекста (например, GoingGoingGone здесь богаче) |

Пересечение большое (20 кат Нила — почти все есть у Теда), поэтому работаем с банком Теда как основным, у Нила берём варианты брифов, где он полнее. Витрины сами по себе простые: правила (`/rules.html`), список (`kata.html?kata=all` у Теда, `/katas/list.html` у Нила), случайный выбор.

## 2. Как задуманы каты (правила оригинала — и что мы берём себе)

Оригинал — **командное** упражнение 3–5 человек с модератором: фазы discussion (команда изучает бриф, задаёт вопросы модератору-«заказчику») → peer review (презентация архитектории другой команде, ответы на вопросы) → voting (палец вверх/вбок/вниз). Правила, которые переносим в соло-тренировку напрямую:

- **Модератор — это все роли сразу** (заказчик, босс, продакт, ops): на реальной секции эту роль играет интервьюер. У нас в моке §6.3 его играет ассистент; в соло-раунде вопросы выписываются на бумагу вместе с принятыми ответами-допущениями.
- «Any technology is fair game… just be prepared to defend its use» — любая технология допустима, но каждый выбор надо уметь защищать. Прямо наш §3 (трейдоффы вслух).
- Допущения о незнакомой технологии разрешены, **если явно озвучены** — на секции то же самое: «допустим, у Kafka задержка X, тогда…».
- «You may not assume developer All-Stars» — не рассчитывать на команду звёзд; для секции это означает: не оправдывать простоту схемы «наберём сильных», а обосновывать её требованиями.
- Peer review и voting → наш self-review по рубрике §6.2: кату «сдаёт» чек-лист этапов, а не чужое голосование.

## 3. Выбранные каты (3 шт. под наш формат)

Критерии выбора: веб-масштаб с числами (есть что считать на этапе 5), домен рядом с разделами брифа, богатый список требований, и — главное — **не пересечение** с эталонами `classic-designs.md` (URL shortener, лента, мессенджер, медиа-хостинг): раунд по кате должен быть встречей с незнакомым брифом, а не повторением эталона.

### 3.1. Concert Comparison — билеты на концерты (основная)

> **Бриф (EN, оригинал):** A concert ticketing site with big acts and high volume needs an elastic solution to sell tickets.
> **Users:** thousands of concurrent users, bursts of up to 10,000/second when tickets go on sale.
> **Requirements:** allow concurrent ticket buying; do not sell a seat more than once!; shoppers can see an overview of remaining seats.
> **Additional Context:** consider an implementation in both Space Based and Microservices architecture style; identify the tradeoffs for each solution.

**Суть по-русски:** площадка продажи билетов на концерты; обычный трафик — тысячи concurrent, при старте продаж топ-артиста — всплеск до 10 000 запросов/сек; нельзя продать одно место дважды; покупатели видят карту остатков мест. Контекст прямо просит сравнить два стиля и назвать трейдоффы.

**Что тренирует (разделы брифа):** 02 (burst RPS, пропускная способность), 03 (эластичное масштабирование, LB), 07 (очередь как развязка всплеска, waiting room), 08 (отказ узла в пик ≠ потеря продажи), 09 (конкурентная запись на инвентаре — reservation/exactly-once на месте). Бонус: единственная ката, где контекст сам требует **сравнить две архитектуры и озвучить трейдоффы** — репетиция «защиты» схемы. Это ближайший родственник flash-sale/распродажи билетов (классика собеседований: Ticketmaster).

### 3.2. I Can Haz Cheezborger? — UGC-платформа трендов

> **Бриф (EN, оригинал):** Client wants to create websites to follow Internet trends — as a new trend is identified, create a website following it and highlighting it and allowing users to interact with it.
> **Users:** millions+ readers, thousands of posters, dozens admins.
> **Requirements:** high SEO; easy for users to add content; easily mashable/clickable; reject inappropriate content; easy trend analysis; user forums; user moderators; ubiquitous accessibility; easy admin «reach»/accessibility.
> **Context (у Нила):** VC-funded startup; wants to harvest data across trends for deeper market analysis; in 10 years wants to be a powerhouse site for Internet trends.

**Суть по-русски:** сеть сайтов, догоняющих интернет-тренды: миллионы читателей, тысячи авторов, десятки админов; SEO, лёгкое добавление контента, отбраковка неприемлемого, аналитика трендов, форумы, модерация.

**Что тренирует:** профиль нагрузки **read-heavy ~1000:1** (миллионы читают, тысячи пишут) — зеркало ленты из `classic-designs.md` §2, но с другим набором проблем: 04 (контент как данные, версионирование), 06 (CDN + кэш чтения, инвалидация), 07 (асинхронная очередь модерации — «reject inappropriate» не делается в request-path), 10 (мультиарендность многих сайтов-трендов), 11 (аналитика трендов = отдельный pipeline). Хорошая ката на «где cache, где CDN, что в очереди».

### 3.3. Going, Going, Gone! — аукционный дом online + live

> **Бриф (EN, оригинал):** An auction company wants to take their auctions online to a nationwide scale — customers choose the auction to participate in, wait until the auction begins, then bid as if they were there in the room, with the auctioneer.
> **Requirements:** auctions must be categorized and «discoverable»; auctions must be as real-time as possible; auctions must be mixed live and online; video stream of the action; handle money exchange; participants must be tracked via a reputation index.
> **Users (у Нила):** hundreds of participants per auction, potentially thousands; as many simultaneous auctions as possible.
> **Context (у Нила):** aggressive expansion by merging competitors; if success — replicate overseas; budget not constrained (strategic direction); company just settled a lawsuit alleging fraud.

**Суть по-русски:** аукционный дом выходит на федеральный масштаб: смешанные аукционы (зал + онлайн), ставки в реальном времени «как в комнате», видеотрансляция, деньги, репутация участников; контекст — недавний иск о мошенничестве.

**Что тренирует:** жёсткая смесь real-time + консистентность: 05 (шифрование ставок не нужно — нужно **порядковость**: последний bid выигрывает, репликация/шардирование по аукционам), 07 (пуш ставок всем участникам — fan-out, WebSocket), 09 (аукцион = точка согласования, linearizability на ставке), 08 (падение ноды посреди аукциона), плюс платежи и immutable-аудит (контекст с иском прямо намекает: репутация и журнал ставок — не опция). Самая сложная из трёх; ставить третьей.

## 4. Резерв (если захочется ещё)

| Ката | Домен | Зачем может пригодиться |
|---|---|---|
| Gird The Grid | платформа управления электросетями, телеметрия near-real-time, 99.99 | единственная ката с явными **четырьмя девятками** — прокачка раздела 08 (SLO, много-ДЦ) и time-series хранилищ (04); телеметрия = observability (12) |
| Who's Your Daddy? | крупнейший генеалогический граф, миллионы пользователей | графовая модель данных (04), API для третьих сторон, краудсорс-верификация записей |
| Make the Grade | стандартизированное тестирование по штату, 40K+ учеников | batch-обработка, очереди заданий, консолидация результатов — разделы 07, 09 |
| Trash Talk | чаты для игровой студии ~1M игроков | пересекается с мессенджером `classic-designs.md` §3 — брать только как повторение эталона |

Полную банк-выкладку (38 кат) смотреть: `kata.html?kata=all` на architecturalkatas.com; случайная ката — главная кнопка «Do one!».

## 5. Отличие ката от билета `classic-designs.md`

| | classic-designs.md (эталон) | ката |
|---|---|---|
| Бриф | знакомый сервис из топа интервью | незнакомый домен, читается впервые |
| Эталон | есть — полный разбор 6 этапов | **нет** — сверка по чек-листу и KB-паттернам |
| Масштаб | дан в билете | часть надо выспросить/зафиксировать самому |
| Что тренирует | паттерны и структуру ответа | этап 1 на незнакомце + стойкость без подсказки |

Поэтому порядок в подготовке: сначала 1–2 раунда по эталонам (каркас ответа отработан, есть с чем сверять), затем 1 раунд по кате — стресс-тест «как на секции», и идеален он накануне слота.