Там же можно без проблем использовать свой VPS.

На самом деле ничего плохого от дистиллята не произойдет. Большая часть всех солей, микроэлементов, и витаминов попадает в организм с пищей а не водой.

Только это будет не микросервис, а распределенный монолит.

Идея в том, чтобы сервису для отдачи данных пользователю не нужно ползти в другие сервисы и что-то там дергать. Сервис просто сидит и ждет апдейтов которые приходят через шину от других. Это сильно уменьшит зависимости между сервисами, что позволит сосредоточиться на обеспечении доступности user-facing сервисов, и меньше думать про сервисы которые работают в фоне.

Лучше через Kafka.

Будет слишком много оверхеда.

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

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

Можно еще быстрее, если написать в анкете что виза нужна «как только так сразу». У меня ушло 4 дня с момента подачи документов до получения паспорта с визой.

Хороший подход :)

А если попробовать реализовать какую-нибудь последовательную CRDT (например LSEQ) поверх дропбокса, то можно добиться вполне приличного слияния при редактировании записей.

Каким образом это реализовано?

Что будет если в офлайне сделать две записи на двух разных устройствах, а потом они начнут синхронизацию? Одна из версий будет перезапишет другую?

Интересно, а аспирантура в СНГ будет цениться на западе?

Учился в Екатеринбурге на инженера-теплоэнергетика, пока вдруг после экскурсии на электростанцию не понял что это не мое и что надо что-то менять. Решил прокачивать навыки computer science на coursera, с 4 курса начал работать, начинал с PHP после чего перешел на Scala. В итоге к 23 годам переехал в Берлин и сейчас работаю в крупнейшей европейской e-commerce компании.

Интересно чем Akka не подошла.

а Scala?

А если воспользоваться подходом CQRS и писать все события в Kafka, а потом отражать изменения на кеше? Данный вариант тоже имеет право на жизнь?

Сам актор — «формула», которая делает одно вычисление. Без состояния.

Это не самый подходящий способ использования акторов. Акторы больше предназначены для безопасного хранения состояния в многопоточной среде, а если состояние отсутствует, то фьюча часто бывает проще и удобнее.

Mongo любит терять данные при нетсплитах (https://aphyr.com/posts/284-call-me-maybe-mongodb). Как предполагается обеспечивать консистентность данных?

Рассматривали ли вы использование akka streams?

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

1. Сообщение отправлено в сеть?
2. Сообщение принято другим хостом?
3. Сообщение получено мейлбоксом?
4. Сообщение начато обрабатываться актором?
5. Сообщение успешно обработано актором?

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