Коммуникация микросервисов. Не пойму как правильно делать

А ты проверяй очередь сообщений в базе, если пуста и mq не лежит, то отправляешь. Если лежит или очередь не пуста, то пишем в базу сообщение

Всё было бы так хорошо, если бы апи параллельно не выполнялись. А они выполняются. Тогда надо перед тем, как отправлять - блокировать сообщения, чтобы параллельно выполняющийся апи2 не продублировал то, что делает апи1

Гугли про cirquit breaker, например. Не надо ничего самому изобретать.

Кроме этого ничего толком не нагугливается https://pypi.org/project/circuitbreaker/

https://martinfowler.com/bliki/CircuitBreaker.html

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

Найти бы готовую реализацию оного под djangorest, чтобы не велосипедить

как быть, если мк2 лежит?

Никак, не проблема, очередь для того и нужна.

как быть, если mq лежит?

Никак, очередь не лежит, в этом вся суть. Сделай кластер.

Если случилось что-то ужасное, и очередь таки лежит, сделай ещё несколько попыток, потом отменяй транзакцию, пиши в лог, что усё пропало, отвечай соответствующим образом на health check.

И не забывай, что БД у тебя тоже может лежать.

4.1 а у нас есть сообщения в локальной базе?
4.1.1 если да, записать в локальную базу.
4.1.2 чего бы не гребнуть сообщения по таймстемпу и не отправить в нужном порядке.

В итоге мы получаем, что сообщение2 отправлено быстрей, чем сообщение1. Это не правильно

отправляй мессаги через подсистему messenger, в нем как раз очередь. код обработки запросов не должен думать об успехе доставки его сообщений. он их отдает мессенжеру, там свой тред, если приемник упал, мессенжер копит мессаги, как только поднялся - отправляет накопленные, если есть, и пробрасывает новые. это единственно верно.

Если mq лежит, то при попытке что-то туда отправить (или еще раньше) твоё приложение свалится, ты не сможешь принимать запросы и все дальнейшие трепыхания бессмысленны. Если же ты допускаешь работу приложения при полудохлой инфраструктуре, то да, накапливай, разгребай воркерами, но это - дичь, брокер должен работать и продублирован раза на 3
Если лежит mk2, то сообщения падают в очередь, когда mk2 оживёт, то начнёт её разгребать.

В итоге мы получаем, что сообщение2 отправлено быстрей, чем сообщение1. Это не правильно

Так сделай велоочередь в мк1 и отправляй последовательно, когда mq поднимется.

В итоге мы получаем, что сообщение2 отправлено быстрей, чем сообщение1. Это не правильно

Почему это? Если у тебя запросы выполняются параллельно, то никаких гарантий, что второе сообщение будет отправлено после первого, нет и быть не может.

как быть, если мк2 лежит?

Поднимать лапки и говорить пользователю, что всё плохо.

как быть, если mq лежит?

Накапливать сообщения? Нет! Тоже поднимать лапки и сознаться пользователю, что рулят сервером дятлы.

Это просто, честно и гарантирует консистентность данных. Всё остальное это чрезмерное усложнение и гипотетическая потеря данных, что недопустимо.

Вообще, как мне кажется, юзер ничего не должен знать о том, что сервисы лежат

Но это будет не просто скрыть от него.

сообщение2 отправлено быстрей, чем сообщение1. Это не правильно

Это пофиг. Перестановка не должна никак влиять. Если влияет - вот это неправильно.

В твоём сценарии сообщение2 и при нормально работающем mq может вперёд пролезть.

Кластер из кроликов делай, можешь с бронебойностью (запись на диск очереди) и все. Пишешь один сервисом и читаешь другим.

То есть один сервис у тебя паблишер, а второй - подписчик.Подписчик не обязан всегда онлайн біть. Как и паблишер. Только очередь должна со 100% аптаймом жить.

Делаешь мониторинг на количество сообщений в очереди и спокойной живешь.

Много сообщений - лежит подписчик.

Долго нет сообщений («долго» у каждого свое и зависит от конкретного приложенька) - плохо паблишеру.

Как тут правильно уже ответили, да, очередь должна быть в кластере, таким образом, что аптайм очереди не меньше аптайма базы. Мы в команде делали ещё чтобы и сами сервисы были в кластере (docker swarm + несколько инстансов сервиса).