Android System Design: Design Firebase library

Коротко о видео

Это учебное ответное system design-интервью для Android-разработчика: кандидат проектирует библиотеку — аналог Firebase — с crash reporting и продуктовой аналитикой. Обсуждаются публичный API SDK, надёжная доставка через локальное хранение и подтверждения бэкенда, приоритетные события, повторные отправки и дедупликация. Во второй части подробно разбираются ограничения перехвата ранних crash на Android, модель хранения аналитики и итоговый фидбек интервьюера.

Затронутые темы

Что взять на заметку

• Сначала сузить задачу до crash reporting и аналитики, явно зафиксировав требования: гарантированная доставка событий, малый вес SDK и идентификация клиента библиотеки.
• Для SDK нужен минимальный публичный API: инициализация с конфигурацией, отправка событий с приоритетом и метаданными, а также возможность вручную сообщить об ошибке; внутренние идентификаторы событий лучше генерировать внутри библиотеки.
• Предложенное разделение хранения: crash сохранять отдельными файлами, а многочисленные события аналитики — в локальной базе данных, чтобы удобно фильтровать, сортировать и отслеживать статусы.
• Гарантия доставки в обсуждаемой модели означает: сначала сохранить данные локально, удалять их только после явного подтверждения от бэкенда, а при ошибке оставлять для повтора с учётом числа попыток.
• Для защиты от дублей при тайм-ауте ответа бэкенда каждому событию нужен внутренний уникальный идентификатор: сервер может распознать уже принятые события и вернуть подтверждение повторно.
• Приоритетные события кандидат предлагает сохранять и отправлять сразу, а обычные — пакетами по порогу количества или таймеру; накопленное также отправлять при следующем запуске приложения и после восстановления сети.