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. Два сборника и что из них брать

Пересечение большое (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. Резерв (если захочется ещё)

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

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

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