Вопросы на собеседовании: Инженер-программист

Я бы построил чтение через кэш и генерировал ключи без центрального узкого места.

• 64-битный Snowflake ID в Base62 даёт ключ примерно из 11 символов; worker ID выдаются уникально, а откат часов останавливает генерацию до появления дубля.
• Cassandra хранит ключ, адрес, владельца и срок жизни в 256 виртуальных шардах, а Redis кэширует горячие соответствия с TTL 24 часа.
• Узел редиректа делает один запрос в Redis, затем при промахе обращается к шарду, оставляя хранилищу около 20 мс внутри бюджета p99 в 100 мс.
• Пять лет при 20 000 записей в секунду дают около 3,2 триллиона строк; при 100 байтах на строку и replication factor 3 нужен примерно 1 ПБ до учёта компактации и резервных копий.

Я бы отделил владение сокетами от надежной обработки сообщений и упорядочивал сообщения по комнате.

• Stateless WebSocket-шлюзы держат примерно по 50 000 соединений и публикуют аутентифицированные сообщения в Kafka с ключом room_id.
• Kafka дает упорядоченную партицию для ключа комнаты, а консьюмеры сохраняют сообщения в Cassandra и публикуют их через Redis Streams на шлюзы получателей.
• p99 200 мс измеряется до online-шлюза получателя: 30 мс на ingress, 80 мс на Kafka и сохранение, 60 мс на fan-out и 30 мс запаса.
• У соединения есть исходящий буфер 16 КБ в пределах общего лимита шлюза 1 ГБ; при переполнении медленный клиент получает resync cursor и отключается.

Я бы хранил байты в объектном хранилище, а приложению оставил только метаданные и координацию загрузки.

• API создаёт multipart upload в S3 и возвращает подписанные URL для частей по 16 МБ, поэтому загрузка файла на 5 ГБ возобновляется с последней подтверждённой части.
• PostgreSQL хранит версии, хэши, владельца и ID multipart upload с уникальным ограничением по tenant_id, пути и версии.
• Клиенты передают checksum SHA-256 для каждой части S3 и итоговый манифест; S3 проверяет байты до атомарной публикации версии сервером.
• Десять петабайт остаются в S3 с lifecycle-уровнями, а уведомления об изменениях используют монотонный курсор пользователя, чтобы офлайн-клиент забирал только пропущенные метаданные.

Я бы вычислял флаги внутри каждого процесса по версионированному локальному снимку.

• API control plane сохраняет определение и outbox row в одной транзакции PostgreSQL, после чего CDC публикует каждую закоммиченную версию в Kafka.
• SDK держит неизменяемую in-memory карту и атомарно меняет снимок целиком, поэтому вычисление занимает O(1) и меньше 1 мс.
• Потоковый gRPC-канал доставляет версионированные дельты, разрыв sequence сразу загружает snapshot, а heartbeat каждые 2 секунды обеспечивает SLO 5 секунд для подключённых исправных SDK.
• При недоступности control plane SDK использует последний корректный snapshot и типизированное жёстко заданное значение по умолчанию, а не блокирует запрос.

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

• Условный UPDATE захватывает свободное или просроченное место и записывает hold_id с expires_at в одной транзакции, поэтому между проверкой и резервированием невозможна гонка.
• Строка места служит точкой сериализации, а индекс по event_id и expires_at позволяет находить просроченные удержания без сканирования события.
• Durable timer table и scheduler публикуют hold_id при истечении; место освобождается только при совпадении hold_id и прошедшем expires_at, поэтому старый таймер не снимет новое удержание.
• API принимает ключ идемпотентности на 24 часа, поэтому повтор клиента возвращает исходное удержание, а не занимает второе место.

Я бы применил fan-out при записи для обычных аккаунтов и fan-out при чтении для знаменитостей.

• Обычные публикации через Kafka попадают в пользовательские ленты Cassandra, ограниченные 1 000 новейших ID.
• Аккаунты с более чем 100 000 подписчиков помечаются как знаменитости, и их публикации остаются в отдельной авторской ленте вместо 50 миллионов записей на пост.
• Сервис читает paged-индекс знаменитостей, пока heap не докажет границу top 20, без фиксированного лимита авторов, который мог бы скрыть публикации.
• Я отвожу 40 мс чтению лент, 60 мс объединению и ранжированию, 60 мс загрузке данных и оставляю 40 мс внутри цели p95 в 200 мс.

Я бы обслуживал запросы из компактного префиксного индекса в памяти и перестраивал его вне горячего пути.

• Офлайн-задача Spark строит взвешенный конечный преобразователь по 5 миллионам фраз с локалью и оценкой популярности.
• Каждый stateless-узел отображает версионированный индекс в память и возвращает 10 лучших продолжений без запроса в удаленную базу.
• Балансировщик распределяет трафик по 180 узлам примерно по 5 600 QPS; после потери 1 из 3 зон оставшиеся узлы держат около 8 400 QPS ниже проверенного предела 10 000.
• Redis-overlay хранит трендовые фразы 5 минут; сервис объединяет этот малый набор с неизменяемым индексом внутри p99 в 50 мс.

Я бы использовал партиционированный лог для приёма и колоночное хранилище временных рядов для сжатых запросов.

• Kafka принимает около 10 ГБ в секунду в 1 500 партиций с ключом из tenant и хэша метрики, удерживая средний ingress партиции ниже 7 МБ/с.
• Консьюмеры пакетируют по 10 000 семплов в ClickHouse MergeTree; 30 дней дают около 26 ПБ raw до compression, поэтому реплики разделены по дням и упорядочены по tenant_id, metric_id и времени.
• Материализованные представления агрегируют данные по сервису в интервалы 10 секунд и 5 минут, поэтому суточный график читает тысячи строк вместо всех исходных серий.
• Квоты отклоняют тенанта выше 1 миллиона активных серий, потому что неограниченные метки разрушат и бюджет хранения на 30 дней, и SLO запроса в 10 секунд.

Я бы разбил задачи по временным бакетам и позволил воркерам независимо арендовать пакеты.

• PostgreSQL партиционирует задачи по часу с индексом next_run_at, а 60 логических шардов ограничивают сканирование каждой минуты.
• Узлы планировщика через SELECT FOR UPDATE SKIP LOCKED арендуют по 1 000 готовых задач на 2 минуты и публикуют их в Kafka.
• Воркеры требуют execution_id и сохраняют завершение с бизнес-эффектом, если у них одна база; для внешнего эффекта нужны idempotency key и outbox.
• Сверка ищет задачи с опозданием больше 2 минут, а лаг планирования выше 60 секунд нарушает заявленную точность.

Я бы сохранял одну надёжную последовательность и одну активную доставку на получателя, включая время ретраев.

• Kafka ingress использует destination_id как ключ в 1 000 партиций, а state store Kafka Streams хранит упорядоченную очередь каждого получателя.
• Диспетчер отправляет только головной элемент; 20 000 async-соединений дают 200 000 доставок/с лишь при измеренной задержке около 100 мс, а 3 секунды служат cutoff, не основой расчёта.
• Ошибка переносит next_attempt_at головного элемента на 1, 5 и 30 минут в пределах 24 часов, не продвигая очередь этого получателя.
• После 5 ошибок circuit breaker открывается только для этого ключа; ожидание в partitioned state store не блокирует исправных получателей той же партиции.

Я бы делил систему по бизнес-владению и транзакционным инвариантам, а не по техническим слоям.

• Catalog владеет товарами и ценами, Inventory резервами, Orders состоянием покупки, а Payments интеграциями с провайдерами и своим реестром.
• Каждый сервис открывает версионированные gRPC-команды и события Kafka, а запрет общих таблиц обеспечивается отдельными схемами PostgreSQL и учетными данными.
• Checkout оркестрирует процесс, но не меняет чужие строки; он вызывает ReserveInventory и AuthorizePayment с явными ID запросов.
• Независимость еженедельных релизов проверяется consumer-driven контрактами в CI, а межсервисные изменения остаются аддитивными минимум два релиза.

Я бы разделил загрузку и обработку на два асинхронных ресурса.

• Клиент загружает файл прямо в S3 по multipart signed URLs, поэтому API не буферизует тело на 500 МБ.
• POST /jobs проверяет метаданные объекта, записывает задачу в PostgreSQL и возвращает 202 с job_id в пределах 2 секунд.
• Kafka только будит workers; worker получает lease PostgreSQL на 20 минут с heartbeat и fencing version до запуска в изолированном пуле.
• GET /jobs/{id} и webhook завершения отдают статус, а отмена остается best-effort, потому что 15-минутный шаг кодека может остановиться не сразу.

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

• PostgreSQL хранит tenant_id, idempotency_key, request_hash, order_id, status и response под уникальным ограничением tenant и key.
• Первый запрос создает запись идемпотентности и заказ в одной транзакции; дубль возвращает сохраненный статус и ответ.
• Тот же ключ с другим хэшем запроса получает 409, поэтому случайная коллизия не меняет смысл незаметно.
• Записи живут обещанные 24 часа, а параллельный дубль опрашивает исходную операцию вместо повторного создания заказа.

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

• OpenAPI-схемы через oasdiff запрещают в CI удаление полей, сужение enum и появление новых обязательных свойств.
• Ломающее изменение получает датированную версию, а старая остается на том же надежном шлюзе полные 12 месяцев.
• Метрики версий по клиентам находят оставшиеся из 10 000 интеграций, а уведомления содержат конкретный endpoint и время последнего использования.
• Шлюз поддерживает обе версии поверх одной канонической доменной модели, не создавая отдельный легаси-парк, который угрожал бы цели 99,99%.

Я бы открыл непрозрачные keyset-курсоры по стабильному уникальному порядку.

• Записи упорядочены по created_at и id, которые поддерживает составной B-tree индекс PostgreSQL.
• Курсор кодирует последнюю пару и хэш фильтров и подписывается HMAC, чтобы клиент не менял позицию и не использовал его с другим фильтром.
• Страница выполняет range-запрос с LIMIT 101, возвращает 100 строк и следующий курсор без сканирования прошлых страниц.
• Вставки после cursor могут появиться в текущем проходе, а вставки до него только в новом; snapshot consistency потребовала бы as-of token.

Я бы сделал новое поле необязательным и сохранял старый смысл события весь период смешанных версий.

• Avro-схемы живут в Schema Registry с FULL_TRANSITIVE compatibility, поэтому старые consumers читают новые данные, а новые могут переиграть сохранённые старые.
• delivery_window является nullable-записью с явным default null и документированной интерпретацией времени в UTC; отсутствие не подменяется выдуманным значением.
• Продюсеры 6 месяцев заполняют старое и новое представления, если существующие поля не выражают новую концепцию чисто.
• Контрактные фикстуры запускаются против всех 40 consumers, а удаление начинается только после нуля чтений старой схемы по их собственной version telemetry.

Я бы использовал оркестрируемую сагу с явными резервами и компенсациями.

• Оркестратор хранит конечный автомат в PostgreSQL и вызывает трех провайдеров со стабильными operation ID и дедлайнами по 9 секунд.
• Перелет и отель создают удержания на 5 минут, а платеж авторизуется, но не списывается до успеха обоих резервов.
• Сбой любого шага запускает идемпотентную компенсацию, освобождающую резервы и отменяющую авторизацию, с ретраями через надежную очередь.
• Через 30 секунд API возвращает confirmed, rejected или pending с booking_id и не объявляет отказ, пока компенсация не завершена или поздний ответ провайдера не обработан.

Я бы использовал append-only реестр с двойной записью и балансами, выведенными из неизменяемых проводок.

• PostgreSQL принимает проводки только через stored procedure с deferred constraint trigger, который до commit проверяет равенство дебета и кредита.
• Проводки счетов партиционируются по месяцам и индексируются по account_id и sequence, а закрытые разделы через год уходят в дешевое хранилище.
• Таблица балансов обновляется в той же транзакции для быстрого чтения, а ночной пересчет сверяет ее с неизменяемыми проводками.
• Исправления делаются обратными проводками со ссылкой на исходную, сохраняя семилетний аудит и жесткий запрет изменений.

Я бы держал свежие семплы в колоночном хранилище с временными партициями, а сжатые разделы архивировал в объектное хранилище.

• Kafka принимает семплы с ключом device_id, а ClickHouse пакетирует вставки в дневные MergeTree-партиции, упорядоченные по device_id и времени.
• Тридцать горячих дней при 3 миллионах семплов в секунду требуют сжатия и репликации; Parquet или Delta в S3 хранят месяцы со второго по двадцать четвертый.
• Запрос по устройству за час использует первичную сортировку и читает узкий диапазон, а часовые min-max-avg проекции обслуживают типовые дашборды.
• Поздние семплы можно писать 48 часов; более старые исправления идут в боковую таблицу, чтобы не переписывать многотерабайтные архивные партиции.

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

• Строки Cassandra с ключом follower_id хранят отсортированные followee ID, распределяя 2 миллиарда связей с частыми добавлениями без межузловых транзакций.
• Обратная таблица с ключом followee_id поддерживает страницы подписчиков; обе записи несут одну версию связи и асинхронно сверяются.
• Redis set кэширует подписки активных пользователей, поэтому взаимность проверяется двумя SISMEMBER существенно быстрее 100 мс.
• Для полного списка взаимных связей пересечение выполняется только при менее чем 100 000 рёбер; для знаменитостей используется предвычисленное подмножество.