Миллион элементов в json - это сильно (жирно).
Предлагаю следующий вариант:
- В качестве брокера использовать любой брокер сообщений/менеджер очередей с ACK/NACK механизмом (Redis Streams, RabbitMQ, Kafka)
- Все json разбиваем на 2 категории - большие и маленькие в зависимости от размера (кот. поддерживает брокер)
Алгоритм будет следующий:
Producer:
- Приходит запрос с json
- Если json маленький, то отправляем в брокер напрямую
- Если json большой, то сохраняем его в отдельную БД и получаем ID этой записи, в брокер отправляем ID этой записи
Consumer:
- Получает сообщение из брокера
- Если json содержится в сообщении (когда маленький), то сохраняем в БД
- Если json был большим и передан ID из БД, то читаем этот JSON из временный БД и сохраняем в целевую БД
- Коммитим сообщение
Пример такого запроса:
// Маленький объект
{
"data": {
"key": "value"
},
"id": null
}
// Большой объект
{
"data": null,
"id": 13123123
}
P.S. название паттерна хранения большого объекта во внешнем хранилище и передача только его id не помню
