iOS Engineering System Design Interview "Analytics Service" | Антон Калюжный | iOS Ukraine #2

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

Запись мок-интервью по System Design для iOS: участник проектирует переиспользуемый сервис аналитики, который отправляет события и ошибки в несколько провайдеров, включая Firebase Analytics, Mixpanel и Flurry. Центральный Analytics Center скрывает детали SDK за единым протоколом, поддерживает инициализацию сервисов, маршрутизацию и фильтрацию событий, а также офлайн-буферизацию. В Q&A обсуждают тестируемость, декораторы для офлайн-логики, кроссплатформенное API, соглашения об именах событий и подготовку к интервью Facebook.

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

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

• На System Design-интервью сначала уточняйте границы задачи: число аналитических провайдеров, необходимость переиспользуемого/Open Source-компонента, типы данных и офлайн-режим.
• Спрячьте конкретные SDK за протоколом AnalyticsService с едиными операциями инициализации и отправки событий; Analytics Center может хранить набор таких реализаций и рассылать им событие.
• Опишите событие как отдельную сущность с именем и параметрами; для предотвращения опечаток используйте типизированные фабрики, enum или структуры вместо произвольных строк по всему приложению.
• В предложенном решении при отсутствии сети событие вместе с timestamp сохраняется локально в JSON-файл и отправляется позднее; UserDefaults автор считает неподходящим хранилищем для этой задачи.
• Не помещайте в аналитические события e-mail, номер телефона и другие персональные данные; вопрос шифрования локального буфера зависит от состава данных и требований безопасности.
• Для отправки разных событий в разные системы добавьте правила допустимых событий или отдельный routing/filtering-сервис; офлайн-буфер и фильтрацию можно вынести в декораторы над общим протоколом.
• Для тестов не привязывайте весь код к singleton: создавайте отдельный Analytics Center и подключайте debug-реализацию сервиса, которая фиксирует полученные события.