В этой подборке вопросы сгруппированы по формату «System Design», чтобы подготовку можно было вести от базовых тем к практическим задачам. В подборке чаще встречаются темы: backend, api, database.
Нужен версионируемый каталог контрактов с владельцами, потребителями, схемами и статусом поддержки. Источником истины удобно сделать репозиторий, связанный с CI и проверками совместимости.
Создайте согласованный snapshot в отдельной версии таблицы, затем догоните изменения через CDC и атомарно переключите читателей на готовую копию. Загрузка частями не должна делать частичные данные видимыми.
Нельзя просто направить весь поток после отказа кэша в БД. Нужны лимит fallback-запросов, объединение одинаковых промахов, короткие timeout и управляемая деградация.
Независимые вызовы нужно выполнять параллельно: время станет близко к максимуму из 10 и 2 секунд. Но сервис, отвечающий за 10 секунд, уже исчерпывает весь бюджет оркестратора.
Kafka доставляет и хранит поток событий, а Postgres может быть источником текущего состояния, транзакций и запросов клиента. Эти роли не взаимоисключающие.
Используйте transactional outbox на стороне отправителя и идемпотентный inbox/бизнес-ключ у получателя. Реалистичная база — повторяемая доставка с однократным эффектом.
Используйте разные конфигурации AnalyticsClient: для первого экрана — console sink, для второго — console и file sink. Запись файла сериализуйте общей очередью.
Разделите сбор событий, очистку данных, локальный журнал с TTL и uploader. Серверные запросы на выгрузку должны проходить через тот же контролируемый pipeline.