День 2592. #Архитектура #ВопросыНаСобеседовании
Проектирование Систем Как Кофейня. Окончание
Начало

Вот как справляться с «наплывом посетителей».

1. Балансировщик нагрузки (Хостесс)
- Аналогия: Вместо того чтобы все одновременно бросались к стойке, вы нанимаете хостесс у входа. Она смотрит на три кассы и говорит: «Вы идете к кассе 1, вы к кассе 2». Она распределяет нагрузку, чтобы ни один бариста не «вышел из строя».
- Технология: Балансировщик нагрузки (например, Nginx или AWS ELB) находится перед вашими серверами. Он направляет входящий трафик на разные экземпляры серверов, чтобы ни один сервер не был перегружен.

2. Кэширование (Готовые продукты)
- Аналогия: Приготовление сэндвича на заказ занимает 5 минут. Если его хотят сразу 50 человек, у вас будут проблемы. Вместо этого вы готовите 50 «популярных» сэндвичей и кладёте их в холодильник. Когда клиент хочет такой сэндвич, он просто берёт его — никакого ожидания.
- Технология: Кэш (например, Redis или Memcached) хранит результаты частых запросов к БД. Если все спрашивают о «Топ-10 самых популярных постов», не нужно обращаться к БД 1000 раз. Храните ответ в памяти для мгновенного доступа.

3. Реплики для чтения (печатные меню)
- Аналогия: Если у вас одно большое меню за стойкой, всем приходится стоять в одном месте, чтобы его прочитать, создавая узкое место. Вместо этого напечатайте 100 бумажных меню и раздайте их посетителям. Теперь все могут читать меню одновременно.
- Технология: Реплики для чтения — это копии основной БД. Основная БД делает ресурсоёмкую работу (прием заказов/запись данных), а «реплики» обрабатывают трафик «чтения» (просмотр профилей или меню). Это предотвращает перегрузку основной БД.

4. Асинхронная обработка (сигнал о готовности заказа)
- Аналогия: Вы не заставляете клиента стоять у кассы, пока готовится его сложный латте. Вы даёте ему метку и предлагаете сесть. «Заказ» оформлен, и бариста работает над ним в фоновом режиме.
- Технология: очередь сообщений (как Kafka или RabbitMQ). Пользователь немедленно получает ответ «202 Accepted», а интенсивная обработка происходит в фоновом режиме, не вызывая «зависания» приложения для пользователя во время ожидания.

Компромиссы
В проектировании систем нет правильных ответов, есть только компромиссы. Если вы сделаете кофейню очень быстрой (предварительно приготовите 100 латте), качество может снизиться (кофе остынет). Если вы сделаете её высококачественной (готовить только под заказ), люди будут стоять час в очереди. «Мы могли бы добавить кэш, чтобы ускорить процесс, но тогда меню может устаревать на несколько секунд. Для кафе это, вероятно, приемлемо».

Вот как бы мы представили «процесс заказа» на собеседовании:
- Запрос: Клиент нажимает «Заказать» в телефоне.
- Ввод: Запрос поступает на балансировщик нагрузки, который отправляет его на доступный веб-сервер.
- Запись: Сервер сохраняет заказ в БД (статус: «Ожидание»).
- Передача: Сервер помещает заказ в очередь сообщений (например, RabbitMQ или Kafka).
- Действие: Бариста (потребитель очереди) видит заказ у себя в системе и начинает его готовить.
- Уведомление: Бариста нажимает «Готово», обновляя БД и отправляя уведомление пользователю.

Распространенные ошибки
- Переход к «Как» до «Что»: не говорите «Я буду использовать AWS Lambda», даже не определив, что делает приложение.
- Избыточное усложнение: не проектируйте систему для миллиарда пользователей, если интервьюер попросил создать приложение для вашего района. Это покажет не ваш ум, вашу расточительность.
- Молчание: если вы молчите, вы не пройдёте собеседование.

Итого
Проектировать системы не значит быть ходячей энциклопедией технических инструментов. Это значит уметь решать проблемы. В следующий раз на собеседовании сделайте глубокий вдох, представьте, что вы просто пытаетесь быстро доставить кофе клиенту, и начните задавать вопросы.

Источник: https://medium.com/@yashgangane987/system-design-is-just-a-coffee-shop-a-stress-free-guide-for-engineers-af3e82dc589e