Реализация AWS Event Sourcing

I'm quite a newbe in microservices and Event-Sourcing

Прочтите выступление Грега Янга Polygot Data, чтобы узнать больше о том, что будет дальше.

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

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

В AWS вы обычно получаете это представление, запрашивая у авторитетного сервиса обновленный список событий (реализация которого может включать пейджинг). Служба может предоставлять список событий, запрашивая DynaModb напрямую или получая самый последний ключ из DynamoDB, а затем просматривая кэшированные представления событий в S3.

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

Обычно я бы использовал SNS (разветвление) для широковещательных уведомлений. Потребители, которым нужна бухгалтерская поддержка для обработки уведомлений, которые они обработали, будут использовать SQS. Но основным каналом для передачи упорядоченных событий является вытягивание.

Я сам не смотрел внимательно на Kinesis - есть несколько общее обсуждение в предыдущих вопросах -- но я думаю, что Кевин Сукочефф что-то понимает, когда пишет

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

Основным вариантом использования Kinesis является сбор, хранение и обработка непрерывных потоков данных в реальном времени. Потоки данных — это данные, которые непрерывно генерируются тысячами источников данных, которые обычно отправляют записи данных одновременно и в небольших размерах (порядка килобайт).

Another thing: the fact that I'm accessing data from another 
microservice stream is an anti-pattern, isn't it?

Что ж, часть смысла разделения системы на микрослужбы состоит в том, чтобы уменьшить связь между возможностями системы. Доступ к данным через границы микросервиса увеличивает связанность. Значит, есть какое-то напряжение.

But basically if I'm using a pull model I need to read 
data from other microservices' stream. Is it avoidable?

Если вы запрашиваете необходимую информацию у службы, а не извлекаете ее из потока самостоятельно, вы уменьшаете связанность — так же, как запрашиваете данные у службы, а не обращаетесь к РСУБД и самостоятельно запрашиваете таблицы.

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

(Наивный пример: при выполнении заказа необходимо знать, когда заказ был оплачен; поэтому ему нужен идентификатор корреляции при совершении платежа, но ему не нужны никакие другие платежные данные.)