Когда делаешь приложение для обмена данными с маркетплейсами, все получается легко и быстро, но когда объемы передаваемых данных вырастают в тысячи или десятки тысяч раз, то появляются задачи совсем другого рода. Ты начинаешь задумываться об архитектуре приложения, выборе правильных инструментов. Но ты уже опытный и решаешь задачу не под текущие объемы, а сразу думаешь наперед, прогнозируешь рост нагрузки, планируешь как будет развиваться архитектура твоего приложения.

Это не доклад о том как надо писать код, и что лучше или хуже, а скорее рассказ про наш опыт и приглашение к обсуждению.

Я расскажу о том как эволюционировал наш подход к созданию приложений, какие решения мы выбрали, а какие протестировали и отвергли, например:

какие у нас существуют ETL процессы: получение данных из API маркетплейсов (товаров, заказов, аналитики и пр.), обработка фидов поставщиков
как мы перешли от команд в cron и очереди задач в БД к celery и брокеру сообщений RabbitMQ
зачем реализовали асинхронный API (обработка запросов от поставщиков с информацией о товарах, заказах, доставке и пр.)
особенности масштабирования воркеров и работу с очередями
организацию периодических задач с помощью celery beat, выполнение отложенных задач
обеспечение надежности: идемпотентные таски, late acknowledgment, перезапуск задач в случае ошибки, оптимизация времени выполнения задач, особенности работы с базой данных
инструменты для мониторинга и хранения логов: Flower, веб-интерфейс rabbitMQ, ELK-стек