Можно ли использовать очередь как временное хранилище?

В одной интеграции, где нужно было соединить 2 системы и ни одну из них нельзя было доработать. Ничего примечательного, скажете вы. Но ни одна из систем не давала нам права и доступ для того, чтобы создать свою базу данных и хранить необходимые данные. Тогда наша команда решила хранить промежуточные данные в очереди. И сейчас расскажу о том, как мы решили эту задачу

🔑 Способ реализации

1️⃣ Настройка очереди
Создаем очередь сообщений, используя любой подходящий инструмент, будь то RabbitMQ, Kafka, AWS SQS или другой брокер сообщений. Важно выбрать правильную конфигурацию очереди, учитывая параметры её размера, времени жизни сообщений и политики повтора попыток обработки. Мы выбрали RabbitMQ.

2️⃣ Отправка сообщений
Срабатывает триггер на старт процесса (получение сообщения извне/ по таймеру и тд), появляются данные, требующие сохранения, и приложение формирует сообщение и отправляет его в очередь. Каждое сообщение содержит данные, необходимые для выполнения задачи позже.

3️⃣ Получение сообщений
Это же приложение подходит к этапу, когда ему нужно воспользоваться сохраненными данными. Для этого вычитывания данных в этом же приложении выделается отдельный поток/процесс, который забирает сообщение из очереди.
Если сообщение успешно обработано и интеграционный поток находится на финальной стадии, сообщение удаляется из очереди.
Если возникает ошибка, сообщение может быть возвращено обратно в очередь для повторной попытки обработки.

4️⃣ Дополнительные настройки
Можно установить время жизни для каждого сообщения в очереди. По истечении этого времени сообщение удаляется автоматически, если оно не было обработано вовремя. Это помогает избежать накопления устаревших данных.
А оповещения и мониторинг помогут отслеживать состояние очереди и оперативно реагировать на ошибки, например, если число неподтвержденных сообщений превысит допустимый порог.

✅ Преимущества подхода
🌀 Упорядоченность: Данные сохраняются в строго определенном порядке (FIFO), что полезно для последовательной обработки.
🌀Надежность: Сообщения сохраняются в очереди до тех пор, пока они не будут обработаны. Если происходит сбой в процессе обработки, сообщение остается доступным для повторной попытки.
🌀Масштабируемость: Система может добавлять или удалять процессы обработки сообщений динамически, улучшая масштабируемость.

‼️Недостатки
🔻Дополнительная сложность: Использование очереди как временной базы данных требует дополнительной инфраструктуры и управления, что может увеличить сложность системы.
🔻Ресурсозатратность: Постоянное поддержание очереди сообщений требует вычислительных ресурсов и места для хранения данных.

📍Рекомендации
Используйте очереди сообщений как временную базу данных только там, где действительно важна последовательность и надежная доставка сообщений и нет других способов.
Убедитесь, что выбранный брокер сообщений соответствует вашим требованиям по производительности, масштабируемости и отказоустойчивости.
Настраивайте политику повторных попыток и удаления сообщений с учетом специфики вашей задачи.

Приходилось кому-то использовать очереди в нестандартных кейсах? Расскажите в комментариях