Комментарии 2
Немного дополню
1) Нейминг и однотипная структурированность важны практически везде. Будь то код, таблицы в БД, названия очередей или классов в коде. Чем однотипнее, тем меньше разборов полетов на тему "как назвать", и тем легче разбираться, т.к. глаза начинают привыкать к шаблону.
2) Только сериализация DTO не всегда спасает. Бывает, из сообщения удаляется важная часть этого DTO, или нужно, чтобы разобралась часть старых сообщений старым механизмом обработки, а новый алгоритм применился к новым сообщениям. И промежуток времени разбора может быть большим. Здесь помимо сериализации помогает выработка подхода к версионированию сообщений в очередях и в целом согласование содержимого сообщений: иногда из сообщения важен только id, а код уже по нему дальше восстанавливает необходимые данные из других источников при обработке. Или некоторые сложные типы данных могут иметь проблемы сериализации, если не уследить.
4) При увеличении фоновых задач появляются взаимосвязи между ними. Помимо id message рекомендую сохранять базовый request-id и parent-id, которые породили сообщение в очереди. Можно использовать для этого тот же трейсинг. Тогда будет легче контролировать путь процесса и понимать путь запроса пользователя, который привел к разбираемому случаю.
Я не понял failed-очереди все же стоит использовать или нет?
Вы сначала говорите что не стоит использовать а потом пишете что у каждого важного транспорта своя failed-очередь
Я хотел бы знать это раньше. Очереди в Symfony