🚕 Проект с микросерверной архитектурой: приложение для заказа такси #RideFlow 🚕

Многие проекты стартуют на простой архитектуре, когда сервер реализован как одно большое приложение - монолит. Работать с ними по-своему интересно, но в какой-то момент возникает ощущение, что развитие карьеры закончилось. Это не так. Есть большие высоконагруженные продукты, например, этот👇

Предлагаю спроектировать систему для заказа такси.

Требования к процессу:
1. Регистрация и аутентификация пользователя
2. Планирование маршрута
3. Выбор такси, подтверждение и оплата заказа
4. Поиск водителей с учетом их текущего местоположения
5. Подтверждение заказа водителем и поездка
6. После поездки:
6.1. Заказ переводится в статус выполненного
6.2. Рассчитывается сумма для выплаты водителю
6.3. С пользователя собирается обратная связь - оценка поездки
7. Выплаты водителям на банковские счета раз в сутки

В компании есть диспетчерская, которая работает 24/7: отвечает на сообщения пользователей и водителей через онлайн-чаты, принимает звонки, следит за автомобилями.

Есть управленческие роли с разным уровнем доступа к данным по платежам, которые контролируют всю финансовую историю: генеральный директор, бухгалтерия и другие.

Развернуть всю систему на одном сервере и сделать одну общую базу данных - отличное и простое решение! Это решение - монолит 🙂 Работать будет, но…

Когда 1000 машин одновременно начнут слать свои координаты в систему или 5000 пользователей за одну минуту попытаются сделать заказы, сбои из-за нагрузки на один несчастный монолитный сервер неизбежны.

Так что для этой системы, даже на этапе стартапа, стоит задуматься о выделении хотя бы нескольких независимых сервер-приложений, которые будут обеспечивать её работу - распределять нагрузку на несколько серверов и баз данных.

Интересная задача? Определенно!

Подобные продукты - рай для аналитиков, которые хотят развиваться и делать уникальные решения для автоматизации.

Стартуем проект, будем прокачивать наши навыки системных аналитиков в архитектуре! 🚀

#АрхитектураGA