План курса / Все задачи / System Design

Логика запроса до системы

Клиент ищет точки на карте

  1. Сначала идет поиск ближайших заведений через Geo Service. Данный сервис возвращает ID заведений
  2. Далее идет запрос в Places Service, чтобы вытащить данные о заведении (карточка)
  3. API Composition Pattern: шлюз получает ID от Geo Service, далее идет в Places Service, чтобы вытащить всю информацию.

Почему не хранить всю инфу о заведениях в одном сервисе?

  1. Позволяет разделить на 2 команды разработки
  2. Проще делать deploy системы
  3. Разные модели данных
    1. Places работает сугубо со структурой заведений (карточка)
    2. Geo же занимается работой с геопространством
  4. Single Responsibility Principle и Separation of Concerns — подход микросервисоной архитектуры

Создание заведения

  1. Admin вносит данные
  2. Places прихранивает их в PG
  3. Делает запрос в GeoService, чтобы добавить в поиск новое заведение
  4. Kafka между Places & Geo Services
    1. После того, как вносится изменение в Places сервис, публикуется event в Topic
    2. Далее этот event вычитывается на стороне places и обновляется локация
    3. eventual consistency между внесением изменений в место и тем, как клиент увидит обновленную инфу
  5. Places кладет статику в Media Service. А он уже в MinIO
  6. Далее Media Service уже сам работает с CDN

Как можно оптимизировать работу с Blob Storage?

В нашей системе админ загружает картинки заведений вместе с остальной инфой. Проблема данного решения - нам через нашу систему нужно перегонять все данные. Какая есть альтернатива - использовать pre-sign URL и event от S3. 

  1. Админ загружает основную инфу на backend
  2. Backend отдает pre-sign URL
  3. Админ напрямую грузит данные blob storage
  4. От blob storage идет event до media storage, который делает доп обработку медиа-контента

Можешь почитать про это здесь: https://fourtheorem.com/the-illustrated-guide-to-s3-pre-signed-urls/