React Frontend Developer

Question 1

Объясните концепцию write concern в MongoDB.

Accepted Answer

Write concern в MongoDB определяет, насколько уверенно клиент хочет быть в том, что операция записи (вставка, обновление, удаление) была выполнена успешно. Это настраиваемая величина, которая может варьироваться от минимальной уверенности до большинства узлов или всей системы.

Question 2

Объясните концепцию уровня подтверждения записи (write concern) в MongoDB.

Accepted Answer

Уровень подтверждения записи (write concern) в MongoDB определяет, сколько узлов репликационного набора должны подтвердить выполнение операции записи (вставка, обновление, удаление), чтобы она считалась успешной. Существует несколько уровней подтверждения:

Unacknowledged: Запись выполняется без ожидания подтверждения.
Acknowledged: Ожидается подтверждение от основного узла.
Majority: Ожидается подтверждение от большинства узлов репликационного набора, что гарантирует сохранность данных.

Question 3

В чём разница между at-least-once и exactly-once delivery? Почему exactly-once сложно реализовать?

Accepted Answer

At-least-once — сообщение может быть доставлено более одного раза, но не потеряется. Exactly-once — доставляется один и только один раз. Последний подход требует координации и идемпотентности на всех уровнях, что делает его реализацию сложной в распределённых системах.

Question 4

Как в Kafka реализовать exactly-once обработку? Какие подводные камни?

Accepted Answer

Exactly-once в Kafka достигается комбинацией idempotent producer + transactional producer/consumer. Подводные камни — сложность конфигурации, накладные расходы на производительность, необходимость идемпотентности в хранилище.

Question 5

Как реализовать дедупликацию событий в Kafka при Exactly-Once потоке без использования транзакций Kafka?

Accepted Answer

Используют внешний idempotency key + хранение последних offsets/IDs в Redis/Postgres.

Каждое событие имеет уникальный ID, и консьюмер проверяет, было ли оно обработано.

Question 6

Какие уровни гарантий доставки сообщений существуют (at-most-once, at-least-once, exactly-once) и как на практике приблизиться к семантике exactly-once?

Accepted Answer

Существуют три уровня доставки: at-most-once (сообщение может потеряться), at-least-once (сообщение будет доставлено, но возможны дубли), и exactly-once (каждое сообщение обрабатывается ровно один раз). Настоящий exactly-once почти невозможен в распределённых системах, но его можно приблизить с помощью идемпотентности обработчика, дедупликации сообщений, транзакций в базе и атомарного подтверждения обработки. Обычно создают таблицу обработанных событий и выполняют операции в рамках одной транзакции, чтобы повторный ретрай не нарушал данные.

Question 7

Какие проблемы возникают при большом количестве NotificationCenter-подписок?

Accepted Answer

Большое количество подписок в NotificationCenter может привести к утечкам памяти и неожиданным вызовам обработчиков. Если подписки не удаляются вовремя, объекты продолжают получать события после деинициализации логики. Также растет связность кода и сложность отладки. В итоге приложение становится менее предсказуемым и устойчивым.

Question 8

Что означают гарантии доставки вроде at-least-once и exactly-once?

Accepted Answer

at-least-once означает, что сообщение будет доставлено минимум один раз, но возможны дубликаты. exactly-once означает, что сообщение будет обработано ровно один раз. Достичь exactly-once сложнее и требует дополнительных механизмов. Большинство систем по умолчанию работают в режиме at-least-once.

Вопросы React Frontend Developer