👋 Всем привет!
Обещала выложить свое решение по задачке, которая была на систем дизайн интервью.

Если коротко, то схема получилась такая:
1⃣ Передача Геолокации курьеров
Устройства курьеров отправляют геолокацию через HTTP-запросы в сервис Геолокации.
Сервис геолокации записывает данные в Кафку.
Из Кафки данные ассинхронно записываются в БД Геолокации и БД Мониторинга.

2⃣Отслеживание курьеров проверяющим
Проверяющий выбирает область для отслеживания на карте - отправляется HTTP-запрос с 2 координатами в сервис Мониторинга курьеров (для упрощения задачи предположили, что можно выделять только прямоугольную область)
Открывается вебсокет соединение для передачи на клиент данных в реалтайме.
Сервис мониторинга получает из БД Геолокации координаты, принадлежащие области, и курьеров. Далее передает данные на клиент.

3⃣Просмотр истории перемещений курьера за период
Проверяющий в фильтре выбирает курьера и период - отправляется HTTP-запрос в сервис Истории. Сервис Истории читает данные из БД Геолокации.

4⃣Очистка истории перемещений за год
Сервис очистки запускается раз в сутки и удаляет из БД Геолокации устаревшие данные.

➕Базы Данных
БД Геолокации - хранит всю историю геолокаций по курьерам за 1 год.
Это реляционная БД (Postgres), тк важна консистентность.

БД Мониторинга - хранит последнюю геолокацию курьера. Кмк хорошо подойдет Redis, тк он производительный и быстрый. Ключ - ИД курьера.

➕ Масштабирование
- Обязательно масштабируем сервис Геолокации с учетом 3300 RPS. На вход ставим балансировщик (условно ngnix, распределять можно раунд робином)
- Шардируем БД Геолокации. Ключ шардирования - по timestamp, чтобы удобно было читать историю. Нагрузку на запись БД выдержать должна, тк пишем асинхронно из Кафки.
- Каждый шард реплицируем.

Из минусов, которые я сейчас вижу на этой схеме:
1. Не проработана история с сохранением настроек области проверяющего.
2. Не хватает API Gateway для распределения запросов между сервисом Мониторинга и Истории.

⚡А как бы вы решали задачу? Мб есть более оптимальные решения)