Платформа заказа поездок городского масштаба держала поездки, водителей и выплаты на бэкенде, который умел падать только целиком: один заблокированный event loop уносил health-check, диспетчеризацию и бронирование разом, а аналитика, нужная всем, обращалась к тем же живым таблицам, что и пассажиры.
Ядро пересобрано как сервис FastAPI на двух воркерах: circuit breaker на каждом горячем пути к Redis, кластеробезопасные очереди с резервной очередью позади и отчётность, снятая с живых таблиц и перенесённая на материализованные представления с обновлением по расписанию — выручка по дням, эффективность по исполнителям, спрос по часам города.
Приложение клиента, приложение исполнителя, консоль партнёров и веб работают в продакшене на AWS против одного закалённого ядра. Зависшая зависимость теперь ухудшает один путь, а не платформу, и вопрос о спросе прошлого месяца получает ответ за секунды, а не обходится стороной.
Нужна такая же система?
Расскажите, что вы строите. В ответ пришлём проработанный план, а не коммерческое предложение.