Проектирование Senior Мобильный system design спрашивают часто обновлено

Мобильный system design: мессенджер

Вопрос

Спроектируйте мобильный клиент мессенджера: личные и групповые чаты, отправка текста и фото, статусы «отправлено/доставлено/прочитано», работа офлайн, push-уведомления.

Коротко

Транспорт: пока приложение открыто, WebSocket для входящих событий и подтверждений; в фоне push (на iOS Notification Service Extension расшифровывает и показывает текст); при подключении догрузка всего пропущенного по последнему серверному номеру события. Данные: локальная база (чаты, сообщения, участники).

Что должно быть в решении

  1. 1
    Требования: типы чатов, медиа, статусы, офлайн-отправка, история, шифрование (обсудить)
  2. 2
    API и транспорт: WebSocket на переднем плане, REST для истории и медиа, push в фоне, курсор синхронизации
  3. 3
    Данные: локальная база чатов и сообщений, клиентский id сообщения, порядковые номера от сервера
  4. 4
    Отправка: локальная запись, outbox, повтор с идемпотентностью, статусы на клиенте
  5. 5
    Синхронизация: догрузка пропущенного по курсору, порядок сообщений, редактирование и удаление
  6. 6
    Узкие места: большие группы, медиа, батарея, доставка push, порядок при гонках

Что спросит интервьюер

  • Как упорядочить сообщения, если часы устройств расходятся?
  • Как работают статусы прочтения в группе на 1000 участников?
  • Что меняется, если нужно сквозное шифрование?

Разбор

Транспорт: пока приложение открыто, WebSocket для входящих событий и подтверждений; в фоне push (на iOS Notification Service Extension расшифровывает и показывает текст); при подключении догрузка всего пропущенного по последнему серверному номеру события.

Данные: локальная база (чаты, сообщения, участники). У сообщения клиентский UUID (для идемпотентности и сопоставления) и серверный порядковый номер в чате, по которому и сортируем: часам устройств не доверяем.

Отправка: сообщение пишется в базу со статусом «отправляется» и в outbox, UI показывает его сразу. Синхронизатор отправляет по сокету или REST, сервер подтверждает с серверным номером и временем, клиент обновляет статус. Повтор безопасен благодаря UUID. Фото: сначала загрузка файла (presigned URL, частями), потом сообщение со ссылкой; превью локально сразу.

Статусы: доставлено и прочитано приходят событиями; в больших группах прочтения агрегируются (счётчик или «прочитали N»), а не по каждому участнику.

Офлайн: история читается из базы, отправка копится в outbox. Узкие места: батарея (сокет только на переднем плане), большие группы, медиа (сжатие, кеш), надёжность push (догрузка при открытии).

Ответьте сами, а не прочитайте

В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.