Асинхронная обработка задач
Интегрировал PostgreSQL и RabbitMQ для очередей задач. Повысил надежность и скорость работы внутреннего сервиса доставки.
Задача
Сеть ресторанов Sushi-Love принимала заказы через внутренний сервис. Каждый заказ обрабатывался синхронно: API получал запрос, проверял наличие позиций, рассчитывал стоимость с учетом акций, отправлял уведомление на кухню, записывал в базу и возвращал ответ клиенту. Весь этот цикл занимал 2-3 секунды. В пятницу вечером и в обеденные часы количество одновременных заказов вырастало в 5-8 раз. Сервер не успевал обработать все запросы - часть падала по таймауту (30 секунд), клиент видел ошибку и уходил к конкурентам. Каждый потерянный заказ - это в среднем 1800 руб. упущенной выручки. За один пятничный вечер терялось до 15-20 заказов.
Решение
Разделил обработку на два этапа: быстрый прием и фоновое выполнение. API теперь только валидирует заказ, создает запись в PostgreSQL со статусом "принят" и отправляет сообщение в RabbitMQ - это занимает 100-200 мс. Клиент сразу получает подтверждение. Дальше воркеры забирают сообщения из очереди и выполняют тяжелую работу: пересчет стоимости, проверка остатков, отправка на кухню, push-уведомления. Каждый воркер работает в транзакции PostgreSQL - если что-то падает, сообщение возвращается в очередь и обрабатывается повторно. Настроил dead letter queue для заказов, которые не удалось обработать после 3 попыток - они попадают в отдельную очередь для ручного разбора. Мониторинг через Grafana: длина очереди, время обработки, количество ретраев.
Результат
Нулевая потеря заказов при любой нагрузке - RabbitMQ буферизует пики, воркеры разгребают очередь за секунды. Время отклика API снизилось с 2-3 секунд до 150-200 мс. В пятничный пик сервис спокойно обрабатывает 200+ заказов в час без деградации. Dead letter queue поймала 3 проблемных заказа за первый месяц, которые раньше просто бы потерялись.
Похожие кейсы
Нужно решить похожую задачу?