TL;DR
System design — это проектирование компонентов, контрактов, потоков данных и эксплуатационных ограничений так, чтобы система достигала целей при нагрузке, сбоях и эволюции. В ArchiPanopticon вы соединяете узнаваемые блоки (шлюзы, брокеры, БД, наблюдаемость, CI/CD и др.) и видите, как меняются throughput, latency, ошибки и утилизация — это близко к тому, как на интервью связывают решения с измеримыми последствиями.
Используйте хаб так: пробегите Темы, пройдите Learning path, углубитесь в Q&A, затем воспроизведите те же потоки на холсте симулятора.
Q&A
Чем system design отличается от enterprise architecture?
System design чаще про конкретный сервис или продуктовый срез: API, хранилище, тактики масштабирования, отказоустойчивость. Enterprise architecture охватывает множество систем, управление и долгоживущую интеграцию. Симулятор ближе к уровню системы, но те же идеи (зависимости, backpressure, наблюдаемость) полезны и для EA.
Насколько глубоко уходить в оценки?
Достаточно показать ход мыслей, а не точность до процента. Обычно оценивают порядки величин: QPS, объём записи, накладные на репликацию, долю попаданий в кэш. Меняя задержки связей или лимиты узлов на холсте, вы делаете похожий what-if анализ.
Где здесь очереди и брокеры?
Они развязывают производителей и потребителей, гасят пики и дают возможность повтора сообщений — ценой сложности эксплуатации и внимания к семантике доставки (at-most-once, at-least-once, «exactly-once» как цель). Если в диаграмме трафик идёт через Kafka или RabbitMQ, спросите себя: что при отставании консьюмеров или рестарте брокера?
Что такое backpressure и зачем он нужен?
Backpressure — это сигнал «вниз по потоку не справляются», чтобы ограничить нагрузку вместо неконтролируемого роста очередей и латентности. Шлюзы и брокеры — естественные места, где в реальных системах и в симуляторе видно давление по метрикам.
Как практиковаться «как на интервью»?
Возьмите постановку (например, сокращатель ссылок, лента, чат). 5 минут — требования и эскиз API; 15–20 — блоки и данные; 10 — отказы и наблюдаемость. Затем соберите это в ArchiPanopticon и объясните каждое ребро через метрики во время эмуляции.
Topics
Темы хорошо ложатся на блоки и связи палитры:
- Требования и SLO — функциональный объём, цели по latency, компромиссы консистентности и доступности (CAP — как мышление, не заученная формула).
- API и слой шлюза — REST/GraphQL/gRPC, завершение аутентификации, rate limiting, маршрутизация.
- Моделирование данных — сущности, паттерны доступа, горячие ключи, эволюция схемы вместе с потребителями.
- Хранение — реляционное vs колоночное vs документное vs объектное; когда помогают репликация и партиционирование.
- Кэш и CDN — TTL, защита от «cache stampede», инвалидация; что на edge, что у origin.
- Мessaging и streaming — топики vs очереди, порядок, consumer groups, DLQ.
- Поиск и аналитика — пайплайны индексации, eventual consistency между OLTP и OLAP.
- Надёжность — таймауты, ретраи с джиттером, идемпотентность, bulkhead, graceful degradation.
- Наблюдаемость — метрики, логи, трассировки; SLO и алерты по пользовательским сценариям.
- Безопасность — границы доверия, секреты, шифрование, WAF и IAM на высоком уровне.
- Поставка — CI/CD, постепенный выкат, дрейф конфигурации как операционный риск.
На каждую тему ответьте: что ломается первым, какая метрика это показывает, какое решение смягчает риск.
Learning path
Практическая последовательность; повторяйте с более сложными задачами по мере роста.
- Основы — прочитайте TL;DR и Q&A. Набросайте простой CRUD API и БД; выпишите три типа отказов (таймауты, частичные падения, всплески трафика).
- Данные и консистентность — для той же задачи решите, где нужна строгая, где допустима согласованность с задержкой. Отметьте сценарии, где устаревшие данные терпимы.
- Масштабирование — добавляйте реплики чтения, кэш или шардирование только там, где это поддерживают паттерны доступа; без лишней сложности.
- Асинхронность — вынесите некритичную работу в очереди или воркеры. Определите идемпотентность для повторов.
- Эксплуатация — добавьте метрики, логи, трассировки и алерты под SLO; проговаривайте инциденты («p99 вырос — что смотреть первым?»).
- Цикл с симулятором — воспроизведите каждый этап в ArchiPanopticon; сравните метрики до и после добавления брокеров, кэша или шлюзов.
Заложите примерно одну сфокусированную сессию на шаг, но держите один сквозной кейс, чтобы накапливалась глубина.
External resources
Опорные материалы (на странице внешние ссылки открываются в новой вкладке):
- Designing Data-Intensive Applications — хранение, репликация, потоковая обработка (сайт книги).
- AWS Well-Architected Framework — надёжность, безопасность, производительность, стоимость.
- Google Site Reliability Engineering (books) — SLO, error budget, реагирование на инциденты.
- CNCF Cloud Native Landscape — карта реальных компонентов (брокеры, mesh, observability), созвучная палитре симулятора.
- HTTP RFC 9110 — семантика методов и терминология кэширования для обсуждения API и шлюзов.
Там — глубина; в ArchiPanopticon — пространственная интуиция, как связи и пути трафика ведут себя под эмуляцией.