История изменений

Касаемо бекграунд воркеров - нормальные делаются на AMQP + воркеры. Те RabbitMQ, Kafka, Storm + консьюмеры с бизнес логикой. Нюансы тут в деплое и управлении этой средой (прод, стейдж, дев стенды, на ровном месте набирается пачка сервисов про которые стоит помнить при деплоях, так что отлаженный CI/CD тут строго обязателен становится).

По реализациям для управления воркерами - я использу Celery. Работает поверх RabbitMQ/Redis и решает задачу по организации выполнения большого кол-ва бекграунд тасков. Юзаю на Python + Django - там все максимально прозрачно получается.

Для организации воркфлоу для него есть какие-то морды, но сам не юзал. Вот пример: https://ovh.github.io/celery-director/ Еще есть веб морда flower для мониторинга его состояния.

По реализации на беке - на моей практике, когда есть бизнес сущности и есть прохождение по некому флоу, то типовой работающий паттерн это создание сущности TaskSomething в базе, который обновляется воркерами и указывает на то, что происходит в воркерах. Это если нужно гарантировать стейт и возможность сделать ретрай на любом шаге (даже если у нас есть умный сервис вокруг). На тысячах тасков в день проблем с таким подходом не предвижу. Опять же, смотри в итоге какой инструмент есть под твой стек - там это может быть из коробки.

Требуются гарантии - делаешь validate тасков в базе раз в N времени. Если видишь проблемы, то включаешь логику по их обработке (откатить изменения, отменить транзакции, кинуть оповещение в людей, что полимеры просираются и тд).

Какой у вас там стек я не знаю, но я бы просто поискал в гугле stacktitle celery analog или stacktitle celery. Задачка в целом типовая, но для разных стеков могут быть разные типовые инструменты ее решения.

PS Для своих проектов, на будущее, посматриваю в сторону n8n и аналогов. Тк, в основном, задачи заключаются в отправке письма, смс, сообщения в месседжер, а это уже тысячи раз решенная задача.

Но тут нужно смотреть на специфику, нагрузку, кодовую базу имеющуюся.

Касаемо бекграунд воркеров - нормальные делаются на AMQP + воркеры. Те RabbitMQ, Kafka, Storm + консьюмеры с бизнес логикой. Нюансы тут в деплое и управлении этой средой (прод, стейдж, дев стенды, на ровном месте набирается пачка сервисов про которые стоит помнить при деплоях, так что отлаженный CI/CD тут строго обязателен становится).

По реализациям для управления воркерами - я использу Celery. Работает поверх RabbitMQ/Redis и решает задачу по организации выполнения большого кол-ва бекграунд тасков. Юзаю на Python + Django - там все максимально прозрачно получается.

Для организации воркфлоу для него есть какие-то морды, но сам не юзал. Вот пример: https://ovh.github.io/celery-director/ Еще есть веб морда flowly для мониторинга его состояния.

По реализации на беке - на моей практике, когда есть бизнес сущности и есть прохождение по некому флоу, то типовой работающий паттерн это создание сущности TaskSomething в базе, который обновляется воркерами и указывает на то, что происходит в воркерах. Это если нужно гарантировать стейт и возможность сделать ретрай на любом шаге (даже если у нас есть умный сервис вокруг). На тысячах тасков в день проблем с таким подходом не предвижу. Опять же, смотри в итоге какой инструмент есть под твой стек - там это может быть из коробки.

Требуются гарантии - делаешь validate тасков в базе раз в N времени. Если видишь проблемы, то включаешь логику по их обработке (откатить изменения, отменить транзакции, кинуть оповещение в людей, что полимеры просираются и тд).

Какой у вас там стек я не знаю, но я бы просто поискал в гугле stacktitle celery analog или stacktitle celery. Задачка в целом типовая, но для разных стеков могут быть разные типовые инструменты ее решения.

PS Для своих проектов, на будущее, посматриваю в сторону n8n и аналогов. Тк, в основном, задачи заключаются в отправке письма, смс, сообщения в месседжер, а это уже тысячи раз решенная задача.

Но тут нужно смотреть на специфику, нагрузку, кодовую базу имеющуюся.

Касаемо бекграунд воркеров - нормальные делаются на AMQP + воркеры. Те RabbitMQ, Kafka, Storm + консьюмеры с бизнес логикой. Нюансы тут в деплое и управлении этой средой (прод, стейдж, дев стенды, на ровном месте набирается пачка сервисов про которые стоит помнить при деплоях, так что отлаженный CI/CD тут строго обязателен становится).

По реализациям для управления воркерами - я использу Celery. Работает поверх RabbitMQ/Redis и решает задачу по организации выполнения большого кол-ва бекграунд тасков. Юзаю на Python + Django - там все максимально прозрачно получается.

Для организации воркфлоу для него есть какие-то морды, но сам не юзал. Вот пример: https://ovh.github.io/celery-director/ Еще есть веб морда flowly для мониторинга его состояния.

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

Требуются гарантии - делаешь validate тасков в базе раз в N времени. Если видишь проблемы, то включаешь логику по их обработке (откатить изменения, отменить транзакции, кинуть оповещение в людей, что полимеры просираются и тд).

Какой у вас там стек я не знаю, но я бы просто поискал в гугле stacktitle celery analog или stacktitle celery. Задачка в целом типовая, но для разных стеков могут быть разные типовые инструменты ее решения.

PS Для своих проектов, на будущее, посматриваю в сторону n8n и аналогов. Тк, в основном, задачи заключаются в отправке письма, смс, сообщения в месседжер, а это уже тысячи раз решенная задача.

Но тут нужно смотреть на специфику, нагрузку, кодовую базу имеющуюся.