System Design: ключевые темы

Junior

Пока нет вопросов для этого уровня сложности.

Middle

Пока нет вопросов для этого уровня сложности.

Senior

1. CAP и PACELC Senior

   Компромиссы консистентности, доступности и задержек; выбор по продукту.
2. Кэширование: CDN/edge и app cache Senior

   Многоуровневый кеш, инвалидации, горячие ключи, stampede защита.
3. CQRS и Event Sourcing Senior

   Разделение чтения/записи и хранение событий; сложность компенсаций.
4. Очереди и стримы (Rabbit/Kafka) Senior

   At-least/at-most/exactly-once семантики, порядок и партиции.
5. Идентификаторы и шард-ключи Senior

   Snowflake/ULID; выбор ключа для балансировки и локальности.
6. Репликация и фейловер Senior

   Leader/follower, кворумы, консенсус (Raft), split brain.
7. Поиск и индексация (Elasticsearch) Senior

   Инвертированные индексы, релевантность, обновления и горячее/тёплое хранение.
8. Идемпотентность и дедупликация Senior

   Idempotency keys, схемы повторов, дедуп по ключам/времени.
9. Backpressure и защита апстримов Senior

   Очереди, лимиты, shed load, таймауты и bulkheads.
10. Бэкапы и DR-план Senior

    RPO/RTO, тесты восстановления, версии схем и совместимость.
11. Монолит vs Микросервисы Senior

    Единое приложение vs независимые сервисы; монолит проще и менее требователен к инфраструктуре, микросервисы масштабируют разработку и независимые релизы ценой сложности сети и согласованности.
12. Горизонтальное vs вертикальное масштабирование Senior

    Добавление серверов vs усиление мощности одного; горизонтальное почти линейно увеличивает throughput, но требует распределения нагрузки, вертикальное упрощает дизайн, но упирается в пределы железа.
13. Балансировка нагрузки (L4 vs L7) Senior

    Распределение трафика между инстансами; L4 (TCP/UDP) на основе адресов, L7 (HTTP) по содержимому (URI, headers); алгоритмы Round Robin, Least Connections, health-check для исключения упавших узлов.
14. Обратные прокси и API-шлюзы Senior

    Reverse proxy (Nginx/HAProxy) принимает запросы и маршрутизирует на сервисы, скрывая их; API-шлюз добавляет авторизацию, лимитирование, кэширование и единый вход для всех API, упрощая интеграцию и контроль доступа.
15. Сервис-дискавери Senior

    Регистрация сервисов в реестре (Consul/Eureka) или DNS для динамического обнаружения; клиенты получают актуальные адреса сервисов по запросу; упрощает масштабирование, но требует отказоустойчивого реестра.
16. Консистентный хешинг Senior

    Распределение ключей по кругу узлов без резкой перестройки при добавлении/удалении узла; минимизирует перебалансировку данных; применяется в кешах (Memcached) и распределённых хранилищах (Cassandra) для равномерной нагрузки.
17. SQL vs NoSQL Senior

    Реляционные ACID-базы vs нереляционные BASE-хранилища; SQL — строгая схема, JOIN, сильная консистентность, вертикальный масштаб; NoSQL — гибкая схема или её отсутствие, шардирование, eventual консистентность, горизонтальный масштаб.
18. Типы NoSQL хранилищ Senior

    Key-Value (Redis) — быстрый доступ по ключу; документные (MongoDB) — JSON-объекты, гибкая схема; колоночные (Cassandra) — масштабируемые широкие таблицы; графовые (Neo4j) — узлы и связи; каждый тип оптимален под свои кейсы.
19. ACID vs BASE Senior

    ACID: атомарность, согласованность, изоляция, надёжность — строгие транзакции; BASE: базовая доступность, мягкое состояние, eventual консистентность — подход NoSQL для масштабируемости; выбор диктуется требованиями к данным.
20. Партиционирование данных (шардинг) Senior

    Разделение базы на шарды для горизонтального масштабирования; стратегии: по диапазону (range) — связанные данные вместе, по хэшу — равномерное распределение; решает рост объёма и нагрузки ценой сложности JOIN и ребалансировки.
21. Кворумные чтения/записи Senior

    Тюнинг консистентности через подтверждения N из M реплик; например W+R > M для консистентного чтения; меньше кворум — быстрее, но возможны устаревшие данные; применено в Dynamo/Cassandra для баланса задержек и согласованности.
22. Multi-master репликация Senior

    Одновременные записи на нескольких узлах (multi-primary); повышает доступность (пишем в ближайший узел), но вызывает конфликты при конфликтующих обновлениях; нужны механизмы разрешения (last write wins, версии); сложнее, часто предпочтительнее master-follower схема.
23. Разрешение конфликтов репликации Senior

    Подходы при рассинхроне данных: last write wins (по метке времени), версионные векторы (обнаружение конфликтующих изменений), вручную через бизнес-логику; нужно для multi-master и офлайн-синхронизаций; компромисс: простота vs возможная потеря данных.
24. Сильная vs eventual согласованность Senior

    Сильная (линеаризуемость) — все узлы сразу видят обновление, данные всегда свежие, но высокая задержка (кворумы); eventual — данные расходятся, но со временем становятся консистентными, высокая доступность и скорость, но читающий может увидеть устаревшее.
25. Paxos vs Raft Senior

    Алгоритмы консенсуса для распределенных систем; Paxos теоретически минималистичный, но сложен в реализации; Raft спроектирован проще для понимания, разделяет роли (лидер, последователи) и процедуры (выбор лидера, репликация лога); оба достигают согласованности при сбоях, предотвращая split-brain.
26. Лидер и выбор лидера Senior

    В кластере реплик один узел выбран лидером (primary) для координации записи; при падении лидера алгоритм (Raft, ZAB в ZooKeeper) проводит выборы нового лидера; требует кворума и таймаутов, чтобы избежать split-brain; лидер обеспечивает единый порядок транзакций.
27. Распределённые блокировки Senior

    Механизм взаимного исключения в распределенной среде (без единой памяти): через хранилище (Redis SET NX, ZooKeeper ephemeral node) создается токен блокировки; требует expiration для снятия при сбое владельца; гарантирует уникальный доступ к ресурсу, но увеличивает задержки и сложности (Dead-lock, потеря блокировки).
28. Распределённое время и часы Senior

    Отсутствие глобальных часов: узлы имеют разные локальные времена; для упорядочивания событий применяют логические часы: лампортовы метки, векторные часы; синхронизация NTP уменьшает дрейф, но не идеальна; в результате трудно определить одновременность событий на разных узлах без специальных протоколов.
29. Когерентность и инвалидация кеша Senior

    Обеспечение консистентности между кешем и источником данных: стратегии — инвалидация кеша при обновлении (отправка нотификации или удаление по ключу), TTL (авто-протухание записей), обновление по подписке; необходимо, чтобы клиенты не читали устаревшие данные из кеша; сложнее в распределенных кешах (несколько нод) — часто используют протоколы коэрентности или единый кеш-координатор.
30. Стратегии кеширования: Cache-Aside, Write-Through, Write-Back Senior

    Cache-Aside: при промахе читаем из БД и кладём в кеш, при обновлении – сначала БД, потом инвалидация кеша; Write-Through: запись идет через кеш сразу в БД (кеш всегда актуален), задержка на запись выше; Write-Back: запись только в кеш, а в БД асинхронно (быстро для пользователя, но риск потери при сбое); выбор зависит от требований к свежести vs скорости.
31. Политики вытеснения кеша Senior

    Алгоритмы удаления элементов при заполнении: LRU (Least Recently Used) — вытесняет давно неиспользуемое, LFU (Least Frequently Used) — наименее частое, FIFO — первое поступило/первое вышло; современные кеши комбинируют подходы (например, TinyLFU); правильная политика учитывает паттерны доступа для минимизации промахов.
32. Dead Letter Queue Senior

    Специальная очередь для сообщений, которые не удалось успешно обработать после нескольких попыток; “ядовитые” сообщения откладываются туда, чтобы не блокировать основную очередь; позволяет отдельно анализировать и исправлять проблемные события, не влияя на поток исправных сообщений.
33. Отложенная (задержанная) обработка Senior

    Выполнение задач с паузой или в заданное время: реализуется через отложенные очереди (сообщения с TTL и последующим переводом в другую очередь) либо специализированные планировщики; используется для повтора с экспоненциальной паузой (retry backoff) или функций “откликнуться через N минут”; требует учёта точности тайминга и сохранности задач при сбоях брокера.
34. Гарантии порядка событий Senior

    Сохранение последовательности сообщений: в Kafka порядок гарантирован внутри партиции, но не между партициями; в RabbitMQ FIFO – в пределах очереди; при масштабировании потребителей (несколько очередей/партиций) глобальный порядок нарушается; решения: выделять ключ партиционирования для связанных событий или вводить компонент ре-секвенсора; возможен компромисс: жертвовать параллелизмом ради порядка.
35. Lambda vs Kappa архитектуры Senior

    Lambda: два канала обработки данных — batch (пакетная обработка исторических данных) и speed (потоковая обработка новых событий) с последующим объединением результатов; сложнее (два кода), но гибко. Kappa: один унифицированный поток (все как события), хранящий и историю, и реальное время, архитектурно проще, но требует потоковых решений даже для исторических данных; выбор зависит от наличия разных требований к свежим и историческим данным.
36. MapReduce Senior

    Модель параллельной обработки больших данных: данные разбиваются и распределяются по узлам (Map-фаза — обработка и вывод пар ключ-значение), затем результаты сортируются и агрегируются (Reduce-фаза); обеспечивает масштабирование на сотни узлов (Hadoop), автоматическую терпимость к сбоям (повтор задач); эффективен для batch-аналитики, но имеет высокую задержку (много проходов по диску).
37. Потоковая обработка данных Senior

    Continuous Streaming – обработка событий в режиме реального времени: системы (Kafka Streams, Apache Flink, Spark Streaming) позволяют считать, агрегировать, фильтровать бесконечный поток с миллионами событий; поддерживаются окна (time windows) для агрегации, обработка out-of-order событий через метки событийного времени; сложность – обеспечить минимальную задержку и устойчивость к всплескам данных.
38. ETL vs ELT Senior

    Extract-Transform-Load: классический подход, когда данные преобразуются перед загрузкой в целевое хранилище (гарантия качества, но занимает время вне БД); ELT: данные сначала загружаются сырыми, а трансформируются уже внутри хранилища (гибкость, можно повторять преобразования по-разному, но требует мощного движка внутри БД); ETL обеспечивает чистоту данных на входе, ELT – скорость сбора и анализ уже в хранилище.
39. Data Lake vs Data Warehouse Senior

    Хранилище-озеро vs классический склад данных; Data Lake – сырые разнородные данные хранятся как файлы (например, на HDFS/S3), дешево и объёмно, для исследовательского анализа и ML, но требуют обработки при чтении; DWH – структурированные данные (схема), агрегированные и чистые, для быстрых BI-запросов (Teradata, ClickHouse); озеро гибкое, но медленное на запросах, DWH быстрый, но жестче по структуре и предварительной подготовке данных.
40. OLTP vs OLAP Senior

    OLTP – системы оперативной транзакционной обработки (частые короткие транзакции, тысячи пользователей, примеры: банковские системы, онлайн-сервисы); OLAP – аналитические системы (редкие тяжелые запросы по большим объемам данных для отчетности, пример: хранилище для BI); OLTP требует оптимизации записи и быстрого отклика (индексы, нормализация), OLAP – оптимизации чтения (денормализация, колоночные базы, MPP кластеры).
41. Денормализация данных Senior

    Сохранение избыточных копий или предрасчетов вместо нормализованных связей для ускорения чтения; уменьшает количество JOIN и снижает нагрузку на runtime, данные доступны напрямую; недостаток – сложнее поддерживать консистентность (обновление требует изменить во всех местах) и растет объем хранения; часто применяется в системах с преобладанием чтения и для кеширования агрегатов.
42. Геораспределенные кластеры Senior

    Развертывание системы в нескольких удаленных локациях/регионах: снижает задержку для локальных пользователей и обеспечивает устойчивость к падению целого датацентра (DR); сложности – репликация данных между регионами (увеличенная задержка, eventual консистентность), маршрутизация пользователей к ближнему узлу (GeoDNS, Anycast), стоимость межрегионального трафика и более сложное тестирование.
43. Multi-tenancy (мультиаренда) Senior

    Одна инсталляция системы обслуживает многих клиентов (тенантов); подходы: выделенный инстанс/база на клиента (изолированно, безопасно, но дорого в обслуживании) vs общие инстансы/БД с разделением по tenant-id (эффективно, но нужно строгое разграничение доступа и возможен “шум соседей”); важны механизмы изоляции, кастомизации настроек на тенанта и балансировка ресурсов между ними.
44. Zero Downtime Deployment Senior

    Выкатка новой версии без простоя: blue-green (две копии среды, переключение трафика с старой на новую после запуска), канареечный релиз (на малую долю трафика, затем расширение), rolling update (постепенное обновление инстансов по одному); требует совместимости версий (схемы БД, API) на переходе, автоматических health-check и возможности быстрого отката при сбоях.
45. CI/CD pipeline Senior

    Непрерывная интеграция и деплой: код при каждом изменении проходит автоматические тесты (CI), затем автоматически или полуавтоматически разворачивается на средах (CD); обеспечивает быстрое и стабильное внедрение изменений; требует инфраструктуры (Jenkins/GitLab CI, Docker registry), хорошего покрытие тестами, и параллельных сред (dev/staging) для безопасной проверки; снижает человеческий фактор и ускоряет выпуск фич.
46. Наблюдаемость (Observability) Senior

    Комплексное отслеживание работы системы: метрики (RPS, latency, ошибки) собираются и строят дашборды, алёрты при выходе за SLO; логирование – централизованный сбор структурированных логов с сервисов (ELK/Graylog) для отладки и аудита; трассировка – присвоение trace-id запросам и сбор информации о пути через микросервисы (Zipkin/Jaeger) для поиска узких мест; хорошая наблюдаемость позволяет быстро выявлять и решать проблемы в проде.
47. Централизованное логирование Senior

    Сбор логов со всех сервисов в единое хранилище (ELK-stack: Elasticsearch + Logstash + Kibana, или облачные аналоги); хранение и индексирование логов позволяет быстро искать ошибки по ключевым словам или trace-id; необходимо стандартизировать формат логов (JSON), чтобы фильтрация и агрегация работали корректно; важна ретеншн-политика (удаление старых логов) во избежание бесконтрольного роста.
48. Пагинация результатов Senior

    Разбиение выдачи на страницы для больших списков; наивный подход — limit+offset, прост, но при больших offset производительность падает и могут быть пропуски/дубликаты если данные обновляются; более надежный подход — keyset pagination: использовать уникальный курсор (ID последней записи на странице) в WHERE для следующей страницы; также применяют курсоры с токеном; пагинация уменьшает нагрузку на БД и ускоряет отклик UI при работе с большими данными.
49. Хвостовая задержка (tail latency) Senior

    Метрика производительности — задержка самых медленных запросов (например, 99-й перцентиль); в распределенной системе суммарный отклик зависит от самого медленного звена (fan-out запросы могут ждать самый медленный сервис); оптимизация: репликация критичных запросов на несколько узлов (берем самый быстрый ответ), ограничение времени ожидания подзапросов (timeouts), устранение узких мест на критичном пути; анализ хвостовых задержек так же важен, как и средней, для хорошего UX.
50. Проблема C10K Senior

    Вызов поддержки 10 тыс. одновременных соединений на одном сервере; традиционный тред-на-соединение подход не масштабируется (нехватка памяти и context switch overhead); решение – неблокирующий I/O (epoll, event loop) и асинхронная модель, позволяющая одному потоку обслуживать тысячи сокетов; например, Nginx и Node.js работают с event loop, Java NIO; масштабирование достигается также горизонтально (несколько серверов за load balancer). Современный рубеж поднялся (C10M), но принципы те же.
51. Нагрузочное тестирование Senior

    Проверка системы под высокой нагрузкой до предела: эмулируются запросы (JMeter, Gatling), постепенно наращивается RPS и измеряются задержки, ошибки, throughput; важно моделировать реальный паттерн (пики, волны), чтобы выявить реальные узкие места; результаты показывают, сколько система выдерживает, где деградирует (CPU, память, БД, сеть); по итогам принимают решения о оптимизации или увеличении ресурсов; также проверяют auto-scaling политики.
52. Модель акторов (Actor model) Senior

    Модель конкурентности, где компоненты (акторы) обмениваются сообщениями асинхронно, вместо совместного доступа к памяти; каждый актор обрабатывает сообщения последовательно, что облегчает написание параллельного кода без блокировок; система акторов (Akka, Orleans) может распределять их по разным узлам, обеспечивая прозрачное масштабирование; обеспечивает изоляцию состояния, но требует продумывать протоколы обмена сообщениями.
53. Gossip-протоколы Senior

    Метод распространения информации в кластере по принципу “слухов”: каждый узел периодически случайно общается с другим и обменивается известными данными (статус узлов, метаданные); обеспечивает eventual консистентность сведений о кластере без центрального координатора; очень устойчив к сбоям отдельных узлов, но сходится не мгновенно; применяется в Cassandra (распространение информации о нодах), Serf/Consul (обнаружение сервисов).
54. Bloom Filter Senior

    Вероятностная структура данных для проверки принадлежности элемента к множеству, которая может давать ложноположительные ответы, но не дает ложноотрицательных; очень компактна по памяти; используется перед обращением к “тяжелому” хранилищу, чтобы проверить отсутствие элемента (например, нет ли ключа в БД) и избежать лишней операции; ложноположительный процент настраивается размером фильтра; широко применяется в кешах, распределенных БД (Cassandra) для ускорения пропускной способности.
55. REST vs gRPC Senior

    REST: HTTP+JSON, человекочитаемо, просто дебажить, хорошо кэшируется (GET); gRPC: поверх HTTP/2, бинарный протокол (ProtoBuf), сгенерированные клиенты, streaming; REST лучше для внешних веб-API (прозрачность, браузерные клиенты), gRPC эффективнее и производительнее для сервис-сервис коммуникаций внутри периметра (низкие задержки, контракт через схемы).
56. GraphQL vs REST Senior

    GraphQL: один гибкий эндпоинт, клиент сам запрашивает нужные поля и структуры – меньше перегрузки данных и запросов; REST: фиксированные ресурсы и эндпоинты, возможны избыточные данные или множественные запросы для составных объектов; GraphQL ускоряет фронтенд-разработку и снижает трафик, но сложнее кешировать и повышает нагрузку на сервер (резолверы, N+1 проблема); REST проще и предсказуемее в эксплуатации.
57. Long Polling vs WebSocket vs SSE Senior

    Long Polling: клиент запрашивает и держит соединение открытым до появления данных или таймаута, после чего сразу открывает заново – имитация push, но с накладными запросами; WebSocket: постоянное двунаправленное соединение, сервер может отправлять данные активно, подходит для интерактивных приложений (чаты, игры) – минимальная задержка, но требует ресурсов на поддержание многих соединений; SSE: серверные события по HTTP (только поток сервер->клиент), проще протокол для stream-уведомлений, но не двусторонний; выбор зависит от требований реального времени и нагрузки (WebSocket наиболее гибок, но тяжелее масштабировать, long polling проще и работает везде, но с задержкой).
58. Блокчейн Senior

    Распределенный реестр транзакций без центрального узла; узлы достигают консенсуса о порядке записей через алгоритмы типа Proof-of-Work (энергоемкий, медленный – биткойн ~7 транзакций/с) или Proof-of-Stake (экономичнее, но с другими рисками); обеспечивает неизменяемость истории и сопротивление цензуре ценой низкой производительности и задержек; применяется там, где нужна доверенная среда между незнакомыми участниками (криптовалюты, децентрализованные приложения).
59. Byzantine Fault Tolerance (BFT) Senior

    Модель отказов, допускающая вредоносное или произвольное поведение узлов; стандартные алгоритмы консенсуса (Raft) предполагают только честные сбои (crash fault), тогда как BFT-алгоритмы (PBFT, Tendermint) работают даже при части скомпрометированных узлов; обычно требуют >=3f+1 узлов для терпимости f вредоносных, и более сложны (много раундов коммуникации); актуальны для блокчейнов и критических систем, где важно работать даже при атаке, ценой производительности.
60. Chaos Engineering Senior

    Практика испытания отказоустойчивости системы через внедрение контролируемых сбоев в продакшене: например, инструмент Chaos Monkey случайно выключает инстансы сервисов; проверяется, устойчиво ли приложение: срабатывает ли автоматический фейловер, перехватывают ли ошибки ретраи, не приводит ли падение одного компонента к краху всей системы; позволяет выявить скрытые зависимости и гарантировать надежность в реальных условиях, при условии, что эксперименты тщательно контролируются и не выходят за допустимые SLO.
61. Автоматическое масштабирование Senior

    Auto Scaling – динамическое добавление/удаление ресурсов под нагрузку: метрики (CPU, количество запросов, длина очереди) мониторятся, при превышении порогов создаются новые инстансы, при спаде – выключаются лишние; важно настроить пороги и “холоддаун” (cooldown), чтобы не было дрожания (флаппинга) при колебаниях нагрузки; позволяет экономить ресурсы и выдерживать внезапные пики; есть реактивное масштабирование (по текущим метрикам) и проактивное (по расписанию или прогнозу).
62. SLA, SLO и error budget Senior

    Service Level Objective – целевой показатель надежности (например, 99.9% аптайма или не более 1% ошибок); SLA – соглашение с пользователями на основе SLO (с выплатой штрафов при нарушении); Error Budget – допустимый “бюджет ошибок”, разница до 100% (например, при SLO 99.9% аптайма, бюджет простоя 0.1% времени), который можно “потратить” на эксперименты, фичи, рисковые релизы; если ошибок слишком много и бюджет исчерпан, замораживаются изменения до восстановления стабильности; баланс инноваций и стабильности по методологии SRE.
63. In-memory vs on-disk хранение Senior

    Данные в памяти (RAM) – нано-/микросекундный доступ, высокопроизводительно (кеши, очереди), но volatile (требует резервного сброса) и ограничено объемом; на диске (SSD/HDD) – персистентно, большой объем, но миллисекундный доступ; гибридные подходы: memory with persistence (Redis снапшоты/AOF), дисковые структуры с кэшированием (страницы в памяти); критичные данные хранят на диске, а для ускорения чтения дублируют часть в памяти.
64. Миграции схем и совместимость Senior

    Изменение схемы БД или API без остановки сервиса: применяют постепенные миграции – сначала расширение (добавить новые поля/версии API, поддерживать и старое, и новое), потом перевод клиентов на новое и только затем удаление старого; каждое изменение должно быть обратно совместимо на этапе деплоя, чтобы старая версия приложения могла работать с новой схемой, и наоборот (при откате); важно тестировать миграции и иметь резервные копии; этот подход позволяет обновлять систему без простоев и без рассинхронизации сервисов.
65. Сетевые partition-ы Senior

    Сбой сети, разделяющий кластер на изолированные части (partition) – большой вызов для распределенной системы (CAP: либо остановить операции, либо риск неконсистентности); стратегии: либо одна из частей берется как основная, а другие ограничиваются на запись (avoid split-brain, пожертвовать доступностью), либо позволить каждой продолжать работать (повышая доступность ценой конфликтов, которые придется разрешать при восстановлении связи); системы консенсуса стремятся обнаружить partition (timeouts) и сохранить один кластер активным; после восстановления связи – слияние данных (конфликт-резолв, синхронизация журналов).
66. Аутентификация и OAuth Senior

    Проверка подлинности пользователей: базовый подход – логин+хеш пароля в базе, поддержка сессий (cookie+session store) для веба; OAuth2/OIDC – стандарт делегирования: пользователь логинится через доверенный Auth-сервер, получает access токен и ID токен, которыми удостоверяется перед другими сервисами; JWT (JSON Web Token) – самодостаточный токен с подписью, позволяет делать аутентификацию stateless (без хранения сессий на сервере), но требует защиты от компрометации (краткий TTL, механизмы отзыва); лучшие практики: соль и сильный хеш для паролей, rate limiting на попытки, MFA для чувствительных систем.
67. Авторизация и контроль доступа Senior

    Определение прав уже аутентифицированного пользователя: модели – RBAC (role-based, пользователям назначаются роли с набором прав), ABAC (attribute-based, решения на основе атрибутов пользователя, ресурса, контекста), ACL (access control lists на ресурсах); в распределенных системах токены (JWT) могут содержать роли/права, чтобы микросервисы могли автономно решать, разрешён ли запрос; важно минимизировать привилегии (least privilege) и своевременно отзывать/изменять права, а также аудит действий (кто что сделал).
68. Шифрование данных Senior

    Защита информации криптографией: в транзите – протокол TLS (HTTPS) шифрует канал клиент-сервер (секретность + целостность), сертификаты X.509 подтверждают личность сервера; в покое – шифрование дисков (Full Disk Encryption) или на уровне БД (Transparent Data Encryption), чтобы при компрометации носителя данные оставались непонятными; также шифруют бэкапы; важно управлять ключами (KMS), менять и защищать их; шифрование добавляет накладные расходы CPU и сложности (ротация ключей, управление доступом), но часто требуется стандартами безопасности.
69. Безопасность API и веб Senior

    Защита веб-приложений на нескольких уровнях: WAF (Web Application Firewall) на периметре фильтрует SQL-инъекции, XSS и др. атаки по сигнатурам; CORS ограничивает вызовы API из браузеров сторонними доменами; CSRF – защита токенами или SameSite cookie; проверка вводных данных (white-list) на сервере предотвращает внедрение опасных команд; использование HTTPS повсеместно; регулярные сканирования уязвимостей и пен-тесты; безопасная конфигурация заголовков (Content Security Policy, HSTS); безопасность должна быть учтена на этапе дизайна API, а не после.
70. Google Spanner и TrueTime Senior

    Spanner – глобально распределенная SQL-база от Google, сочетающая масштабируемость NoSQL с транзакционной консистентностью; ключ – сервис TrueTime, выдающий всем узлам время с известной погрешностью (эпсилон); транзакции используют метки времени, ожидая эпсилон для уверенности в порядке – обеспечивает линейнуюизуемость (сильную консистентность) по всей планете; реализует распределенный 2-фазный commit с монолитным ощущением для клиента, но требует синхронизированных атомных часов и высокоскоростных сетей между датацентрами; это компромисс CAP с упором на Consistency + Partition Tolerance, жертвуя минимальной задержкой (PACELC: “EL”).
71. Outbox-паттерн Senior

    Шаблон надежной интеграции БД и брокера сообщений: при изменении данных вместо прямой отправки события сообщение записывается в локальную таблицу-«outbox» в рамках той же транзакции, что и изменения в данных; отдельный процесс или поток читает outbox и публикует события в очередь (Kafka, RabbitMQ); гарантируется, что событие не потеряется (если транзакция закоммитилась, оно точно в outbox) и не будет отправлено без сохранения данных; решает проблему dual-write; нужно чистить старые записи outbox и обрабатывать дубли на приемной стороне (идемпотентность).
72. Контейнеры vs виртуальные машины Senior

    Контейнеры (Docker) – легкие изолированные окружения, разделяют ядро ОС, запускаются за секунды, позволяют высокой плотностью размещать приложения; ВМ – полноценные гостевые ОС на гипервизоре, сильная изоляция, но тяжелые (минуты на загрузку, оверхед ресурсов); контейнеры удобны для микросервисов и CI/CD, ВМ – для жесткой изоляции и разнообразных ОС; часто используются вместе: ВМ как узлы, внутри них множество контейнеров; контейнеры требуют внимания к безопасности (общее ядро), ВМ – к эффективности (оверхед).
73. Капасити-планирование Senior

    Оценка необходимых ресурсов для будущей нагрузки: анализ метрик роста пользователей и данных, прогнозирование RPS и объема хранилищ; сценарии пиковых нагрузок (например, акция – X10 обычного трафика); план закупки или выделения ресурсов с запасом (compute, storage, network) заранее, чтобы не допустить нехватки; включает расчеты, например, что 1 сервер обрабатывает N RPS, нужно M серверов для ожидаемого пика + резерв; регулярный пересмотр планов по мере изменения тенденций; помогает избежать перегрузок и оптимизировать расходы.
74. Edge Computing Senior

    Выполнение части вычислений на “краю” сети – ближе к источнику данных или пользователю (IoT-девайсы, локальные узлы) вместо центрального датацентра; снижает задержки (обработка рядом), экономит канал (отправляются уже агрегированные данные), позволяет работать при временном отсутствии связи; примеры: предобработка данных сенсоров на шлюзе, CDN-функции на edge-серверах; вызовы – управление множеством распределенных узлов, обновления ПО, безопасность данных вне центра.
75. Форматы сериализации: JSON vs Protobuf Senior

    JSON – текстовый, человекочитаемый, не требует схемы, но избыточен по объему и медленнее парсится; Protocol Buffers (protobuf) – бинарный компактный формат, требует определения схемы, генерирует классы для данных, быстро кодируется/декодируется; JSON удобен для веб-API и интеграций (легко читать, отлаживать), protobuf – для внутренних сервисов с высокими требованиями к производительности и четкому контракту; также protobuf обеспечивает эволюцию схем (optional поля) без поломки старых клиентов.
76. Прикидочная оценка нагрузки Senior

    Грубый расчет параметров системы на этапе дизайна: например, ожидается 1 млн пользователей, каждый делает 5 запросов в день, пиковый concurrency 5%, итого ~3 RPS средне и до 50 RPS пик – хватит 1 сервера или нужно 2? Также оценить размер данных: если каждый запрос сохраняет 1KB, за год ~365*1e6*1KB ~ 365GB; такие оценки помогают выбрать архитектуру (нужен ли кеш, шардинг) заранее, выявить потенциальные проблемы; они неточны, но дают порядок цифр для планирования, а потом проверяются нагрузочными тестами.
77. Amazon Dynamo архитектура Senior

    NoSQL ключ-значение (AP по CAP) от Amazon: полностью децентрализован, без мастера; использует консистентный хешинг для распределения данных, каждый кусок данных хранится с N-кратной избыточностью на разных узлах (фактор репликации); читатели/писатели используют кворумы R/W, позволяя настройку консистентности; применяется механизм разрешения версий (вектора версий) – при конфликтующих обновлениях сохраняются обе версии (eventual consistency, разрешение на стороне клиента); ввел идею “gossip”-протокола для обмена состоянием между узлами и Merkle-деревья для синхронизации данных фоновыми процессами; послужил основой для Cassandra и Riak.
78. Распределённая ФС (GFS/HDFS) Senior

    Хранилище файлов для big data: файл разбивается на большие чанки (64-128MB) и хранится на многих дата-нодах с репликацией (обычно 3 копии); центральный мастер (NameNode) держит метаданные – какие чанки составляют файл и где лежат, а data-ноды хранят сами блоки; при чтении/записи клиент обращается к NameNode за списком node, затем напрямую к ним; такая архитектура оптимизирована под последовательную запись и чтение огромных файлов (логов, видео) – позволяет параллельно читать разные чанки; HDFS (Hadoop) – open-source реализация GFS от Google, лег в основу экосистемы Hadoop/MapReduce; ограничение – не подходит для большого количества мелких файлов и для сценариев с частым изменением файлов.
79. Pub/Sub vs Point-to-Point Senior

    Шаблоны обмена сообщениями: Pub/Sub (издатель-подписчик) – сообщения по теме получают все подписчики (пример: уведомление о событии уходит всем заинтересованным сервисам), асинхронно и без ответа; Point-to-Point (очередь задач) – каждый сообщение получает ровно один получатель (воркер) и обычно требует подтверждения обработки (ACK); Pub/Sub хорош для широковещательных событий и масштабирования распределенной логики, но каждый подписчик должен быть готов к дубликатам и порядку, P2P – для распределения нагрузки работ между воркерами; многие брокеры (RabbitMQ, MSMQ) поддерживают оба режима через exchange/queue механизмы.
80. Infra as Code (IaC) Senior

    Инфраструктура как код: управление сетями, VM, балансировщиками и прочим через описания (Terraform, CloudFormation, Ansible) вместо ручной настройки; конфигурации хранятся в git, проходят code review, позволяют воспроизводимо создавать среды (dev/stage/prod) с одинаковыми параметрами; ускоряет provisioning (новый сервер по скрипту за минуты), устраняет “дрейф” конфигураций; требует освоения инструментов и поддержания шаблонов в актуальности, но значимо улучшает стабильность и масштабируемость инфраструктуры, особенно в облаке.
81. Feature Flags (флаги функциональности) Senior

    Механизм условного включения функционала: вместо деплоя отдельной ветки кода, код выпускается в прод выключенным, а затем включается переключателем (флагом) для всех или части пользователей; позволяет делать A/B тесты, канареечные включения новых фич без перезагрузки приложения, мгновенный откат (выключить флаг); реализуется конфиг-сервисами или переменными окружения + проверками в коде; важно не накапливать “мертвые” флаги и следить, чтобы выключенные пути не отстали (в идеале удалять код флага после окончательного включения).
82. Облако vs on-premise Senior

    Размещение системы в облачной инфраструктуре vs своих серверах; облако (AWS, GCP, Azure) дает быстрое масштабирование, управляемые сервисы (DBaaS, queues), оплату “по потреблению”, но зависимость от провайдера, возможна высокая стоимость при больших объемах, регуляторные ограничения; on-premise – полный контроль, свои датацентры или сервера, постоянные капитальные затраты, выгодно при стабильной высокой нагрузке, но долго масштабировать (закупка железа) и нужно своей команде эксплуатировать; часто используют гибрид: чувствительные данные и стабильные нагрузки on-prem, а пики и новые сервисы – в облаке.
83. Пулы потоков и соединений Senior

    Переиспользование ограниченного количества ресурсов для обслуживания множества запросов: пул потоков – заранее созданные N потоков, которые берут задачи из очереди (вместо создания нового потока на каждую задачу), снижая накладные расходы и ограничивая параллелизм; пул подключений к БД – поддержание открытых TCP-сессий к базе, чтобы не тратить время на установление соединения для каждого запроса, и ограничение одновременных запросов к БД (не больше, чем пул); важна правильная размерность пулов: слишком мало – недоиспользование ресурсов, слишком много – конкуренция и истощение (блокировки, таймауты).
84. Производительность vs стоимость Senior

    Технические решения обычно нужно соотносить с бюджетом: максимальная производительность (минимальные задержки, 0 даунтайма) часто требует значительных затрат (избыточные реплики, топовое железо, глобальные CDN); оптимизация стоимости – поиск компромиссов: например, терпимый рост latency на 20% может сильно снизить расходы (меньше серверов или использование более дешевых ресурсов); в облаке – выбор правильных типов инстансов, использование спотов/резервирования, отключение простаивающих ресурсов; идеал – достичь SLO наиболее экономичным путем.
85. Стриминг видео Senior

    Передача видео контента в интернет в масштабе: видео разбивается на сегменты (4-10 секунд) и распространяется через CDN (серверы по всему миру кешируют сегменты, снижая задержку и нагрузку на origin); используется адаптивный битрейт (HLS, MPEG-DASH): клиент запрашивает сегменты разного качества в зависимости от скорости сети, предотвращая буферизацию; серверы подготовки трансформируют видео в несколько разрешений и битрейтов заранее; Live-стриминг добавляет сложности – минимизация задержки (протоколы WebRTC или Low-Latency HLS), масштабирование на большое число одновременных зрителей (может применяться peer-to-peer между клиентами); важно раздавать нагрузку, храня популярные сегменты на edge и используя эластичность облака для пиковых событий (спортивные финалы).
86. Уровни изоляции транзакций Senior

    Степени изолированности параллельных транзакций в СУБД: Read Uncommitted – могут читаться незакоммиченные чужие изменения (грязное чтение); Read Committed – только коммитнутые данные (грязных нет), но возможно неповторяющееся чтение (между двумя чтениями данные обновились); Repeatable Read – одни и те же строки в пределах транзакции возвращают одинаковые значения (неповторяемых нет), но возможны фантомы (добавленные новые строки); Serializable – полная изоляция, транзакции как будто последовательно, но сильно снижает параллелизм; большинство SQL-БД по умолчанию Repeatable Read или Read Committed, а распределенные часто используют Snapshot Isolation (близко к Repeatable Read без фантомов) для баланса изоляции и производительности.
87. Loose Coupling и High Cohesion Senior

    Принципы дизайна: слабая связанность – компоненты минимально зависят друг от друга (общаются через стабильные интерфейсы, детали реализации скрыты), изменение одного не требует переписывать другой; высокая сплоченность – компонента отвечает за логически цельную задачу, функции, которые меняются по одной причине, сгруппированы вместе; в микросервисной архитектуре это означает выделение сервисов по доменным границам (bounded context), с четко определенными API между ними; достигается система, которую легче поддерживать, изменять и масштабировать независимо.
88. Закон Конуэя Senior

    “Организации, создающие системы, проектируют их структуры копируя свои коммуникационные структуры” – архитектура приложения отражает структуру команд и взаимодействия между ними; например, если над системой работают 4 изолированные группы, выйдет 4 модуля с минимальным взаимодействием; Senior-инженеры учитывают это: иногда, чтобы улучшить архитектуру, меняют организацию (кросс-функциональные команды под микросервисы), а иногда проще принять существующую коммуникацию и спроектировать соответствующие модули; важно помнить, что человеческий фактор влияет на технический дизайн.
89. Одна БД vs несколько (на сервис) Senior

    В монолите все сервисы часто используют одну общую базу данных, что упрощает централизованную консистентность (можно делать JOIN между любыми таблицами) и администрирование, но приводит к сильной связанности – изменения схемы или загрузки влияют на всех, трудно разграничить доступ; в микросервисах практикуют отдельную БД на каждый сервис (owning service) – сервис полностью отвечает за свои данные, что позволяет автономно менять схему и масштабироваться, но глобальные операции требуют межсервисной коммуникации (eventual consistency через события вместо прямых JOIN); компромисс: на старте может быть общая БД, но при росте системы лучше разделить по bounded context, синхронизируя через API/события.
90. Time Series базы данных Senior

    Специализированные БД для временных рядов (метрик, логов с метками времени): оптимизированы под большой поток записей по времени и запросы по диапазонам времени; используют сжатие данных (разницу между соседними значениями, битовые поля), автоматическое аггрегирование/downsampling старых точек; часто хранят данные по принципу “сейчас в памяти, старое на диске” или разделение на горячие/холодные партиции; примеры: InfluxDB, TimescaleDB (расширение Postgres), Prometheus (встроенная TSDB); позволяют эффективно строить графики метрик и вычислять агрегаты по временным окнам, но требуют контроля ретеншна (удаления старых данных) из-за больших объемов.
91. Ложные предположения распределённых систем Senior

    Классические 8 заблуждений (Peter Deutsch): сеть надёжна; задержка нулевая; пропускная способность бесконечна; сеть безопасна; топология неизменна; транспорт бесплатен; единый администратор; сеть однородна. В реальности сеть падает, сообщения идут с задержкой, канал ограничен, могут подслушать, топология меняется (масштабирование, сбои), передачи данных стоят денег, есть разные админдомены и технологии – учитывая это при проектировании (таймауты, ретраи, шифрование, кэш, автоконфигурирование), система будет гораздо надежнее и предсказуемее.
92. Цепочка микросервисов (critical path) Senior

    Когда запрос проходит через множество сервисов последовательно, общая надежность и задержка определяется самым слабым звеном цепочки; вероятность сбоя = произведение надежностей всех сервисов (множество зависимостей увеличивает риск отказа), latency суммируется; подходы: выявлять критический путь (tracing, диаграммы последовательности), оптимизировать его – кэшировать ответы от медленных сервисов, вызывать независимые сервисы параллельно (параллелизм вместо последовательности), упростить слишком длинные цепочки (слияние сервисов или CQRS); важно устанавливать таймауты на каждый межсервисный вызов, чтобы сбой одного не блокировал всю цепочку.
93. P2P vs клиент-сервер Senior

    Децентрализованная пиринговая сеть vs классическая модель с сервером; P2P – все узлы равноправны, обмениваются ресурсами напрямую (например, BitTorrent – участники одновременно скачивают и раздают), нет единой точки отказа, хорошо масштабируется с числом узлов, но сложнее обеспечить поиск и консистентность, возможны проблемы доверия и безопасности; клиент-сервер – централизованный сервер предоставляет ресурсы клиентам, проще управление (сервер контролирует данные, безопасность), но сервер – bottleneck и точка отказа, нужно масштабировать (кластеры, балансировка); P2P подходит для распределения нагрузки между участниками, клиент-сервер – для контролируемых сервисов.
94. Pets vs Cattle (сервера) Senior

    Подход к управлению серверами: “Pets” – как домашние питомцы: каждого лелеют, дают имя, настроен вручную, при болезни лечат (тщательно восстанавливают); “Cattle” – как скот: пронумерованные идентичные экземпляры, которых не жалко, при падении заменяются новым из шаблона; современный DevOps стремится к модели cattle: автоматизированное развертывание серверов по образу, без ручных уникальных настроек, и легкое уничтожение/создание; это обеспечивает масштаб и отказоустойчивость (никакой сервер не уникален), но требует инфраструктуры для управления конфигурациями и мониторинга автоматических перестроек.
95. Event Loop модель Senior

    Однопоточная асинхронная модель обработки: один поток (цикл событий) извлекает задачи/события из очереди и исполняет их по очереди; пока задача ждет I/O, поток не блокируется, переключается на другие события; используется в Node.js (JS), Python asyncio, Go runtime (концептуально); позволяет легко масштабировать обработку большого числа соединений (I/O-bound) без создания тысяч потоков, но не использует многопоточность для CPU-bound задач (там нужно либо выносить на отдельные потоки/процессы, либо ждать); требует писать весь код неблокирующим, что сложнее для логики; выигрывает в простоте памяти и контекстов, однако сложнее отлаживать из-за инверсии управления (callbacks/promises).
96. Webhooks vs Polling Senior

    Взаимодействие по инициативе сервера vs клиента: Polling – клиент периодически опрашивает сервер на наличие обновлений (простая реализация, но либо задержки (если редко опрашивать), либо лишняя нагрузка (если часто)); Webhook – сервер при событии сам делает HTTP-запрос на зарегистрированный URL клиента с данными, клиент сразу получает обновление (нет лишних запросов, минимальная задержка), но клиент должен поднять эндпойнт и обеспечить его доступность/безопасность; Webhooks разгружают сервер (нет тысяч опросов) и улучшают UX скоростью, но сложнее в отладке (двустороннее взаимодействие) и требуют повторных попыток отправки при неответе клиента.
97. Синхронная vs асинхронная репликация Senior

    Метод репликации данных из мастера на реплики: синхронный – мастер ждет подтверждения от реплики перед ответом клиенту, гарантия что данные записаны хотя бы на 2 узлах (0 RPO), но увеличивает задержку для пользователя; асинхронный – мастер отвечает сразу, а реплики получают обновление позже, минимальная задержка для клиента, но если мастер упадет до отправки репликам – последние записи потеряются (непримененные на реплике транзакции); синхронная репликация используется для критичных данных (банки) где потеря недопустима, асинхронная – для web-приложений, аналитики, где важнее скорость и допускается небольшой RPO.
98. LSM-tree vs B-Tree Senior

    Структуры данных для индексирования на диске: B-Tree (InnoDB, PostgreSQL) – сбалансированное дерево, данные хранятся в упорядоченных страницах, хорошие времена чтения по ключу и диапазону, но при записи обновляет страницы in-place (может быть рандомный I/O); LSM-tree (Cassandra, ClickHouse) – лог-структурированное слияние: все новые записи пишутся последовательно в конец (в память (MemTable), затем на диск как сортированные SSTables), чтения собирают данные из нескольких файлов, периодически фоновые compaction сливают файлы и удаляют старые версии; LSM даёт высокую пропускную способность вставки/записи (последовательный I/O) и отличное сжатие, но чтения сложнее (может потребоваться заглянуть в N файлов) и паузы на compaction; выбор движка зависит от нагрузки: write-heavy с большим объемом – LSM, read-heavy с частыми выборками по индексам – B-Tree.
99. Архивирование и ретеншн данных Senior

    Управление жизненным циклом данных: активно используемые данные хранятся на быстрых носителях, а устаревшие/редко запрашиваемые переводятся в архив (более дешевое хранение – холодное облако, ленты) или агрегируются (сжимаются, усредняются); политика ретеншн определяет, как долго хранить разные виды данных (например, логи – 1 год, транзакции – 7 лет для регуляторов); архивация снижает стоимость хранения и ускоряет работу основных БД (меньше объем – быстрее запросы), но требует процессов для извлечения архивных данных при необходимости; важен баланс – удалять то, что точно не понадобится, и безопасно хранить то, что нужно долго (шифрование, репликации).
100. Разделение вычислений и хранения Senior

     Архитектурный принцип “compute и storage раздельно”: данные хранятся централизованно (например, в S3 или сетевом хранилище), а вычислительные узлы (серверы приложений, аналитические кластеры) не имеют собственного стораджа, а лишь временно кешируют или запрашивают нужные данные; это позволяет независимо масштабировать хранение (растет объем – увеличили S3) и вычисления (увеличили/уменьшили число серверов под нагрузку), упрощает замену узлов (они stateless); примеры: serverless функции, которые берут данные из общего хранилища, Snowflake (раздельные compute warehouse и единое хранилище данных); минус – увеличение сетевых задержек на доступ к данным, поэтому требуют быстрых сетей, кеширование часто используемых данных и продуманное разделение горячих и холодных данных.