В этой подборке вопросы сгруппированы по формату «System Design», чтобы подготовку можно было вести от базовых тем к практическим задачам. В подборке чаще встречаются темы: backend, api, database.
Уточните, кто считается первым покупателем: начавший оплату или успешно оплативший, и что делать при отмене. Все кассы должны обращаться к общему сервису, который атомарно выдаёт не более десяти резервов.
Ограничьте время ожидания, число параллельных обращений и очередь к медленной зависимости. Добавьте circuit breaker, контролируемые повторы и деградацию, чтобы один сбой не занял все ресурсы цепочки.
Зафиксируйте вместимость слота на уровне БД: уникальность для одного места либо атомарное уменьшение остатка для нескольких. Проверка «свободно» перед отдельной записью не защищает от гонки.
Достаточно event_id, типа события, aggregate_id, payload, created_at, published_at и полей повторов. Нужны первичный ключ и индекс для поиска ещё не опубликованных событий в порядке обработки.
Сначала уточните тип поиска: точное имя, префикс, подстрока или опечатки. Для небольшого справочника начните с обычной БД; B-Tree и триграммный индекс решают разные варианты поиска.
Сначала прекращайте приём новой работы и организуйте контролируемое завершение зарегистрированных задач до закрытия пула БД. Для гарантии восстановления после убийства Pod нужна сохранённая очередь или запись задания.
Идемпотентность означает, что повтор одного запроса не создаёт новый бизнес-эффект. Idempotency-Key должен связывать операцию с сохранённым результатом, а не просто передаваться в заголовке.
Не выпускайте образ с невоспроизводимой готовностью зависимостей. Добавьте ограниченное ожидание/повторы подключения, корректные probes и интеграционную проверку в окружении, похожем на Kubernetes.
Отделите внутреннего пользователя от способов входа: единый user_id и таблица внешних идентичностей provider + subject. Подключайте провайдеров через адаптеры, сохраняя общий контракт сессии для приложений.
Сначала подтвердите регистрацию, затем создавайте активный заказ по надёжному событию. Если заказ нужен раньше, храните его как черновик и активируйте только после успешной регистрации.
Используйте постепенную замену экземпляров, readiness-проверки и завершение активных запросов. Несовместимую миграцию разбейте на expand–migrate–contract, чтобы обе версии временно работали с одной схемой.
Redis может атомарно проверить остаток и создать резерв через Lua-скрипт, не выполняя отдельные read и write. Но защита от overselling требует согласования долговечного учёта и отказов.
