Вопросы на собеседовании: Бэкенд-разработчик

CAP утверждает, что распределённая система одновременно гарантирует не более двух из трёх свойств: согласованность, доступность и устойчивость к разделению сети.

• Разделение сети неизбежно, поэтому реальный выбор, это согласованность против доступности во время него.
• Биллинговый реестр: PostgreSQL с синхронной репликацией для CP, с кратковременным режимом только для чтения при failover.
• Хранилище предпочтений: Cassandra для AP, так как устаревшие данные допустимы, а недоступность нет.

Я начинаю с худшего случая: что будет, если пользователь или бизнес прочитает устаревшие данные.

• Корзина и счётчики ленты переносят устаревание, а остатки на счёте и резервы товаров нет.
• Строгая согласованность стоит латентности и доступности, поэтому по умолчанию я беру eventual consistency.
• Компенсирующие механизмы добавляю только там, где этого требует бизнес-корректность.
• Я документирую решение, чтобы команда не откатилась к строгой согласованности под давлением.

CQRS разделяет модель записи и модель чтения, позволяя оптимизировать каждую независимо.

• Сторона записи обеспечивает бизнес-инварианты на нормализованной доменной модели.
• Сторона чтения материализует денормализованные проекции под конкретные запросы.
• Окупается, когда нагрузки на чтение и запись расходятся, чтения требуют дорогих агрегаций или нужны несколько представлений данных.
• Для простого CRUD-сервиса это чистый оверхед.

Event Sourcing сохраняет каждое изменение состояния как неизменяемое событие в append-only логе вместо перезаписи строк.

• Даёт полный аудит-лог и возможность воспроизводить события для восстановления состояния или новых проекций.
• Естественно сочетается с CQRS.
• Сложности: эволюция схемы исторических событий, стратегии снепшотов при росте потоков, мышление событиями вместо текущего состояния.
• Чтение текущего состояния требует проекции, а не простого поиска по строке.

Я заставляю клиента передавать уникальный ключ идемпотентности, обычно UUID, в заголовке запроса.

• Сервер сохраняет ключ вместе с результатом через атомарный upsert.
• Повторный запрос с тем же ключом возвращает исходный ответ без повторного выполнения платежа.
• Ключи истекают через безопасное окно, обычно 24 часа, чтобы ограничить рост хранилища.
• Запись идемпотентности и выполнение платежа идут в одной транзакции базы, поэтому никогда не расходятся.

Я использую Redis с алгоритмом sliding window log или token bucket в виде sorted set или счётчика с TTL.

• Каждый инстанс атомарно выполняет Lua-скрипт, чтобы проверка и уменьшение не разбивались на сетевые вызовы.
• Для очень высокой нагрузки держу локальный in-process счётчик, синхронизируемый с Redis каждые 100 мс.
• Это допускает небольшое превышение лимита, но убирает Redis из горячего пути.
• Я отдаю заголовки rate limit, чтобы клиенты грамотно применяли backoff.

Я следую паттерну expand-and-contract.

• Добавляю новую колонку как nullable или с дефолтом, затем деплою код, пишущий и в старую, и в новую колонку.
• Заполняю исторические строки небольшими батчами, потом удаляю старую колонку в отдельной миграции, когда все чтения перешли на новую.
• Использую CREATE INDEX CONCURRENTLY в PostgreSQL, чтобы избежать блокировок таблицы.
• Миграции рассматриваю как код: в системе контроля версий, запуск в CI, никогда не вручную в production.

Двухфазный коммит связывает доступность и выстраивает всех в очередь за блокировками во время фазы подготовки.

• Он удерживает блокировки у всех участников, поэтому один медленный сервис становится системным узким местом.
• Ему нужен координатор, который может стать единой точкой отказа.
• Вместо него я использую паттерн Saga: каждый сервис выполняет локальную транзакцию и публикует событие.
• При отказе шага компенсирующие транзакции откатывают предыдущие шаги, исключая связанность и конкуренцию за блокировки.

Saga разбивает многошаговую транзакцию на локальные транзакции с компенсирующими действиями.

• Хореография: каждый сервис реагирует на события предыдущего шага, децентрализованно и легко расширяется без изменения существующего кода.
• Оркестрация: центральный координатор вызывает каждый шаг последовательно, проще трассируется, но завязана на оркестратор.
• Хореографию выбираю для простых потоков, где команда ценит автономность сервисов.
• Оркестрацию выбираю для сложного ветвления, повторов или единого источника истины о состоянии транзакции.

Service mesh вроде Istio или Linkerd внедряет sidecar-прокси в каждый pod для обработки cross-cutting concerns без изменения кода приложения.

• Он даёт mTLS, балансировку, повторы, таймауты, circuit breaking и наблюдаемость единообразно.
• Издержки: каждый прокси добавляет CPU и память на pod.
• Издержки: control plane добавляет операционную сложность, а отладка через два слоя прокси значительно тяжелее.
• Внедряю его только когда у команды есть зрелость для эксплуатации и общая библиотека не покрывает эти задачи.

Я начинаю с key-value хранилища, отображающего короткие коды на длинные URL.

• Redis для горячих чтений с долговечным хранилищем вроде DynamoDB.
• Генерирую коды через base62-счётчик из выделенного ID-сервиса или пул предгенерированных кодов, чтобы избежать единой точки отказа.
• CDN обрабатывает редиректы на edge для популярных ссылок, снижая чтения до единичных миллисекунд.
• Ограничиваю путь записи и отправляю аналитику кликов в Kafka асинхронно, не блокируя редирект.

Backpressure сигнализирует продюсерам о перегрузке консюмеров, чтобы очереди не росли безгранично.

• В Kafka я настраиваю max.poll.records и размер батча и слежу за consumer lag как основным сигналом здоровья.
• Когда lag превышает порог, я оповещаю и могу динамически добавить инстансы консюмеров.
• Для внутренних реактивных пайплайнов использую ограниченные очереди.
• Либо отбрасываю сообщения в dead-letter, либо блокирую продюсера, в зависимости от допустимости потери данных.

Вертикальное партиционирование делит таблицу по столбцам, а горизонтальное (шардирование) распределяет строки по узлам.

• Вертикальное переносит редкие или большие колонки в отдельное хранилище, снижая I/O в частых запросах.
• Шардирование распределяет нагрузку и на чтение, и на запись по ключу шарда.
• Вертикальное использую, чтобы хранить blob в объектном хранилище, а метаданные в Postgres.
• Шардирую, когда один узел не тянет запись или объём, выбирая ключ, который равномерно распределяет записи без кросс-шардовых запросов.

Подход зависит от допустимого устаревания данных.

• Преимущественно статические справочные данные: TTL-инвалидация с достаточно коротким окном.
• Данные, которые должны быть свежими сразу после записи: write-through, обновление кеша и базы вместе.
• Сложная кросс-сущностная инвалидация: публикую событие, и каждый инстанс сбрасывает затронутый ключ.
• Избегаю cache-aside с ручной инвалидацией в масштабе, поскольку это порождает гонки между чтениями и записями.

PostgreSQL даёт ACID, богатые запросы и простые инструменты, но модель single-primary становится узким местом в масштабе.

• Лаг репликации растёт при высоком устойчивом потоке записей.
• Cassandra распределяет записи по всем узлам без единого primary, давая линейную масштабируемость и active-active репликацию.
• Компромиссы Cassandra: нет joins, ограниченные вторичные индексы, таблицы проектируются под доступ заранее.
• Cassandra выбираю, когда записи превышают возможности одного Postgres primary, а паттерны запросов известны и просты.

MVCC, multi-version concurrency control, создаёт новую версию строки на каждое обновление вместо блокировки строк при чтении.

• ID транзакций определяют, какую версию видит транзакция, поэтому чтения не блокируют запись и наоборот.
• Цена в том, что старые версии строк накапливаются, пока VACUUM их не освободит.
• Если autovacuum не успевает, раздувание таблиц и wraparound transaction ID становятся серьёзными рисками.
• Я мониторю раздувание и мёртвые кортежи и агрессивно настраиваю autovacuum на высокообновляемых таблицах.

Я нахожу медленные запросы через pg_stat_statements и EXPLAIN ANALYZE, прежде чем что-то добавлять.

• Проверяю, не является ли узким местом последовательное сканирование большой таблицы.
• Создаю частичные индексы на отфильтрованных подмножествах и составные индексы в порядке предиката.
• Добавляю covering-индексы с INCLUDE, чтобы избежать heap fetch, и всегда использую CREATE INDEX CONCURRENTLY.
• Ревизирую существующие индексы на дубли и неиспользуемые через pg_stat_user_indexes, ведь каждый замедляет любую запись.

PostgreSQL порождает процесс на каждое соединение, поэтому тысячи прямых соединений очень дороги по CPU и памяти.

• Pooler вроде PgBouncer держит небольшой пул реальных соединений и мультиплексирует через них запросы приложения.
• В режиме transaction он переиспользует соединение сразу после коммита, обслуживая тысячи соединений приложения десятками реальных.
• Я запускаю PgBouncer как sidecar или отдельный сервис и настраиваю max_client_conn под ожидаемый параллелизм.
• Мониторю время ожидания пула как сигнал его недостаточного размера.

Read replicas перестают помогать, когда primary насыщается или реплики отдают слишком устаревшие данные.

• Они не спасают, когда запись primary насыщает I/O диска или CPU.
• Они не спасают, когда лаг репликации делает чтения с реплик неприемлемо устаревшими или датасет перерастает один узел.
• Следующие шаги: вертикальное масштабирование, разделение горячих таблиц на выделенные инстансы, кеширующий слой или шардирование по ключу распределения.
• Я исчерпываю вертикальное масштабирование и кеширование до шардирования, которое сильно усложняет запросы и приложение.

Я нахожу запрос в pg_stat_statements, отсортированном по total_time или mean_exec_time.

• Запускаю EXPLAIN (ANALYZE, BUFFERS) на read replica или с коротким statement_timeout, чтобы избежать длинных блокировок.
• Ищу последовательные сканы, nested loop с высокими оценками строк или высокие buffer hits, говорящие о давлении на память.
• Типичные исправления: целевой индекс, переписывание коррелированного подзапроса в join или ANALYZE для обновления устаревшей статистики.
• Любое создание индекса или перезапись сначала обкатываю в non-production окружении.