SlideShare a Scribd company logo
Microservices interaction at scale
using Apache Kafka
• Software engineer at Upwork
• 3500 logged hours
• ivanursul.com
2
Agenda
1.Monolith to Microservices
2.Communication patterns
3.Apache Kafka
4.Kafka in details
3
Anti - Agenda
1.Pros/cons of microservices
architecture
2.How to build microservices right
4
Monolith to Microservices
Module 1 Module 2 Module 3 Module 4 Module 5
Database layer
Network layer DTO
Business
Model
ER
Model
5
Reality
6
7
Microservices goals
8
Scaling in terms of people
4 engineers 2 engineers 1 engineer
9
Scaling in terms of data
10
Service independence
11
Microservices
communication
12
Shared database
13
14
Database per service pattern
15
Service interfaces
16
Services equality
Microservice 1 Microservice 2
2000 rps
KO
2000 rps
200
rps
17
External request
Critical path
18
Consistency
19
Asynchronous messaging
20
Two types of data
Data-on-the-
outside
for your
storage
Data-on-the-
inside
for other services
21
“Pluggable” architecture
22
23
What is Apache Kafka ?
1.Distributed publish-subscribe
messaging system
2.Fast, Scalable, Durable
3.Created at LinkedIn, is now an Apache
project
4.confluent.io 24
time
Commit Log
msg
1
msg
4
msg
7
msg
10
msg
13P0
P1
P2
2x
2x
2x
Distributed Commit Log
Distributed, Replicated
Commit Log
msg
2
msg
5
msg
8
msg
11
msg
14
msg
3
msg
6
msg
9
msg
12
msg
15
25
Apache
Zookeper
Broker
Broke
r
Broke
r
Produc
er
Consum
er
Kafka Streams
Connec
t
Conne
ct
Send messagesRead messages
Zookeper for configuration
Adapter for
third-party
sources
At least one Broker/Node
Consume, process
and produce messages
Apache Kafka architecture
Kafka Cluster
26
Kafka usage patterns
1.Event Sourcing
2.Change Data Capture
3.Kafka Connect
27
Event Sourcing
28
Microservice 1 Microservice 2
Apache
Kafka
29
Write Request Read Request
Kafka Producer
Microservice 1
Command Query Responsibility
Segregation
UI
Write Model Read Model
Write DB Read DB
Event
s
Service structure
Microservice group
Write
Service
Event
Handler
Read
Service
2 instances 2 instances 3 instances
Benefits
32
1.Separate read and writes
2.Data can be replayed
3.Debugging
32
Drawbac
ks
1.Higher learning curve
2.Backward compatibility support
3333
Change Data Capture
3434
3535
Database
Cache
Search engine
Request
update/invalidat
e
Database
Request
insert
updat
e
delete insert
updat
e
Cache Search Index
WAL
3636
37
Bottled water
Apache
Kafka
Microservice infrastructureLegacy monolith
extract changes
38
Apache
Kafka
extract changes
39
Benefits
40
1.Useful for legacy databases
2.Eliminate dual writes
Drawbac
ks
1.Not every DB has support for CDC
2.Database upgrade
41
Kafka Connect
42
Apache
KafkaKafka
Connect
43
Benefits
44
1.Useful for legacy Databases
2.Eliminate dual writes
3.Supported by all storages
4.Custom connectors
Drawbac
ks
1.Additional queries
2.Indicator fields
45
Demo
Key
Roles:
Order
Service
Customer
Service
Frameworks
46
Kaf
ka
Customer
Service
Order
Service
New Order
5 order.payment.processed
4 order.processed
event handler
1 order.created
2 order.created
event handler
47
Apache Kafka in details
48
Anatomy of topic
Kafka
Topic
P0
P1
P2
msg 0
Topic is
divided
into
multiple
partitions
(P0, P1,
P2)
Each message
has an identifier
called offset
Producer
s write
message
s to the
end of
partitionPartition is a
unit of
parallelism
Consumers
can read from
any offset
Message
can have
key:value
msg 3
msg 1 msg 4 msg 7 msg 8
msg 2 msg 5
msg 6
49
Producers
• Publish to topics
• Round-robin
• Murmur 2
• Retry, Batching
• Async
• Broker list
50
Kafka Broker
0 1 2 3 4 5 6 7
0 1 2 3
0 1 2 3 4 5
0 1 2 3 4 5 6 7
0 1 2 3
P
0
P
1
P
2
0 1 2 3 4 5 6 7
0 1 2 3
0 1 2 3 4 5 0 1 2 3 4 5
Leader
partition
Replica
Each partition has
exactly one
leader
0 1 2 3 4 5 0 1 2 3 4 5
And >= 0 replicas.
They’re called In-
Sync Replicas
All read and
writes are made
using leader
partitionBroker 1 Broker 2 Broker 3
0 1 2 3 4 50 1 2 3 4 5
0 1 2 3 4 5 6 7
0 1 2 3
P
0
P
1
P
2
P
0
P
1
P
2
51
Consumers
• Multiple consumers
• List of partitions
• Offset management
• Offset backup to consumer_offsets
52
Consumer Groups
P0 P1 P2
Instance 1 Instance 1 Instance 2 Instance 1Instance 2Instance 3Instance 4
consumer group 1 consumer group 2 consumer group 3
Kafka
Cluster
53
Historical rewind
P0
Current Offset
Instance 1
Instance 1
Service 1
ms
g 1
msg
2
msg
3
msg
4
msg
5
54
Retention period
P0
P1
P2
msg
12
msg
15
msg
11
msg
14
msg
10
msg
13
msg
1
msg
4
msg
7
msg
2
msg
5
msg
8
msg
3
msg
6
msg
9
55
Log compaction
key 1 ->
value
key 2 ->
value
key 1 -> new value
56
Guarantees
• Messages are appended in the order
they send
• Ordering is guaranteed within partition
• Consumer reads a messages in the
order they are stored
• N - 1 Broker failures57
Delivery semantics
• at least once - by default
• at most once - configurable
• exactly once - Kafka Transactions, June
2017
58
Worst scenario
Unclean Leader Election
0 1 2 3 4 5 6 7
0 1 2 3
P
0
P
1
P
2
0 1 2 3 4 5
0 1 2 3 4 5 6 7
0 1 2 3
P
0
P
1
P
2
0 1 2 3 4 5 6 7
0 1 2 3
P
1
P
2
0 1 2 3 4 5
P
0
0 1 2 3 4 5
Leader
partition
Replica
Broker
1
Broker
2
Broker
3
0 1 2 3 4 5
0 1 2 3 4 5 6 7
0 1 2 3
0 1 2 3 4 5 6 7
0 1 2 3 4 5
0 1 2 3 4 5 6 7
0 1 2 30 1 2 3
Sync
0 1 2 3 4 5
0 1 2 3 4 5 6 7
0 1 2 3
Choose one of
the
unsynchronized
followers
Wait for Broker 1
to recover
59
Service Deployment
• No significant problems in producer side
• Consumers may have issues with blue-
green deployment
• Remember to reserve additional
partitions for blue and green stacks
60
Monitoring
• Broker, Producer and Consumer has
JMX support out of the box
• Additional option is to write custom
reporters
61
Kafka Streams
62
Apache Kafka
63
• Useful for large services
• Fault tolerant
• Consume, process and produce
messages
• Aggregations
• Stateful processing
• Distributed joins 64
Why Kafka ?
• Kafka doesn’t acknowledge messages
• Easy to use
• Configurable
• Super fast for reading tail messages
Summary
• Build an event driven backbone
• Add Service interfaces where needed
• Don’t forget about CDC and Kafka
Connect
66
www.slideshare.net/KennyBastani/in-the-eventual-consistency-of-succeeding-at-microservi
Do what makes sense
But don’t build microservices without events
Demo, Slides
ivanursul.com/microservices-interaction-apache-kafka
68
QA
69

More Related Content

PPTX
Cassandra under the hood
PDF
Cassandra and Spark
PDF
Introduction to Cassandra Architecture
PPTX
Tales From The Front: An Architecture For Multi-Data Center Scalable Applicat...
PPTX
PlayStation and Cassandra Streams (Alexander Filipchik & Dustin Pham, Sony) |...
PDF
Comparing high availability solutions with percona xtradb cluster and percona...
PDF
RedisConf18 - Fail-Safe Starvation-Free Durable Priority Queues in Redis
PPTX
Devops kc
Cassandra under the hood
Cassandra and Spark
Introduction to Cassandra Architecture
Tales From The Front: An Architecture For Multi-Data Center Scalable Applicat...
PlayStation and Cassandra Streams (Alexander Filipchik & Dustin Pham, Sony) |...
Comparing high availability solutions with percona xtradb cluster and percona...
RedisConf18 - Fail-Safe Starvation-Free Durable Priority Queues in Redis
Devops kc

What's hot (20)

PDF
Voldemort : Prototype to Production
PPT
MYSQL
PDF
The Hows and Whys of a Distributed SQL Database - Strange Loop 2017
PDF
Robust ha solutions with proxysql
PPTX
The Missing Manual for Leveled Compaction Strategy (Wei Deng & Ryan Svihla, D...
PDF
Scylla Summit 2016: Outbrain Case Study - Lowering Latency While Doing 20X IO...
PDF
Voldemort Nosql
PDF
Why stop the world when you can change it? Design and implementation of Incre...
PPTX
RedisConf18 - Redis as a time-series DB
PDF
Ramp-Tutorial for MYSQL Cluster - Scaling with Continuous Availability
PDF
Distribute Key Value Store
PDF
CockroachDB: Architecture of a Geo-Distributed SQL Database
PDF
Running a distributed system across kubernetes clusters - Kubecon North Ameri...
PDF
Breda Development Meetup 2016-06-08 - High Availability
PDF
Jay Kreps on Project Voldemort Scaling Simple Storage At LinkedIn
PDF
HDFS Selective Wire Encryption
PDF
Best practice-high availability-solution-geo-distributed-final
PDF
Scaling with sync_replication using Galera and EC2
PDF
Kafka Needs no Keeper( Jason Gustafson & Colin McCabe, Confluent) Kafka Summi...
PDF
MariaDB MaxScale
Voldemort : Prototype to Production
MYSQL
The Hows and Whys of a Distributed SQL Database - Strange Loop 2017
Robust ha solutions with proxysql
The Missing Manual for Leveled Compaction Strategy (Wei Deng & Ryan Svihla, D...
Scylla Summit 2016: Outbrain Case Study - Lowering Latency While Doing 20X IO...
Voldemort Nosql
Why stop the world when you can change it? Design and implementation of Incre...
RedisConf18 - Redis as a time-series DB
Ramp-Tutorial for MYSQL Cluster - Scaling with Continuous Availability
Distribute Key Value Store
CockroachDB: Architecture of a Geo-Distributed SQL Database
Running a distributed system across kubernetes clusters - Kubecon North Ameri...
Breda Development Meetup 2016-06-08 - High Availability
Jay Kreps on Project Voldemort Scaling Simple Storage At LinkedIn
HDFS Selective Wire Encryption
Best practice-high availability-solution-geo-distributed-final
Scaling with sync_replication using Galera and EC2
Kafka Needs no Keeper( Jason Gustafson & Colin McCabe, Confluent) Kafka Summi...
MariaDB MaxScale
Ad

Similar to Microservices interaction at scale using Apache Kafka (20)

PDF
Kafka in action - Tech Talk - Paytm
PPTX
Streaming in Practice - Putting Apache Kafka in Production
PDF
Introduction to apache kafka
PDF
Building zero data loss pipelines with apache kafka
PPTX
Kafka RealTime Streaming
PDF
Apache Kafka Scalable Message Processing and more!
PPTX
Getting Started with Kafka on k8s
PDF
Kafka syed academy_v1_introduction
PDF
Apache Kafka - Martin Podval
PPTX
Evolutionary Systems - Kafka Microservices
PPTX
Kafkha real time analytics platform.pptx
PDF
Non-Kafkaesque Apache Kafka - Yottabyte 2018
PPTX
Kafka overview v0.1
PPTX
Fundamentals and Architecture of Apache Kafka
PDF
Implementing Domain Events with Kafka
PDF
Apache Kafka - Scalable Message Processing and more!
PPTX
Apache Kafka - Messaging System Overview
PDF
Kafka zero to hero
PDF
Apache Kafka - From zero to hero
PDF
Strimzi - Where Apache Kafka meets OpenShift - OpenShift Spain MeetUp
Kafka in action - Tech Talk - Paytm
Streaming in Practice - Putting Apache Kafka in Production
Introduction to apache kafka
Building zero data loss pipelines with apache kafka
Kafka RealTime Streaming
Apache Kafka Scalable Message Processing and more!
Getting Started with Kafka on k8s
Kafka syed academy_v1_introduction
Apache Kafka - Martin Podval
Evolutionary Systems - Kafka Microservices
Kafkha real time analytics platform.pptx
Non-Kafkaesque Apache Kafka - Yottabyte 2018
Kafka overview v0.1
Fundamentals and Architecture of Apache Kafka
Implementing Domain Events with Kafka
Apache Kafka - Scalable Message Processing and more!
Apache Kafka - Messaging System Overview
Kafka zero to hero
Apache Kafka - From zero to hero
Strimzi - Where Apache Kafka meets OpenShift - OpenShift Spain MeetUp
Ad

Recently uploaded (20)

PPTX
VVF-Customer-Presentation2025-Ver1.9.pptx
PDF
Wondershare Filmora 15 Crack With Activation Key [2025
PPTX
assetexplorer- product-overview - presentation
PPTX
Oracle E-Business Suite: A Comprehensive Guide for Modern Enterprises
PDF
Digital Strategies for Manufacturing Companies
PPTX
history of c programming in notes for students .pptx
PDF
top salesforce developer skills in 2025.pdf
PDF
Digital Systems & Binary Numbers (comprehensive )
PDF
Designing Intelligence for the Shop Floor.pdf
PDF
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
PDF
Design an Analysis of Algorithms I-SECS-1021-03
PDF
Adobe Premiere Pro 2025 (v24.5.0.057) Crack free
PDF
EN-Survey-Report-SAP-LeanIX-EA-Insights-2025.pdf
PDF
SAP S4 Hana Brochure 3 (PTS SYSTEMS AND SOLUTIONS)
PPTX
Introduction to Artificial Intelligence
PDF
Nekopoi APK 2025 free lastest update
PPTX
Embracing Complexity in Serverless! GOTO Serverless Bengaluru
PPTX
CHAPTER 2 - PM Management and IT Context
PDF
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025
PDF
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
VVF-Customer-Presentation2025-Ver1.9.pptx
Wondershare Filmora 15 Crack With Activation Key [2025
assetexplorer- product-overview - presentation
Oracle E-Business Suite: A Comprehensive Guide for Modern Enterprises
Digital Strategies for Manufacturing Companies
history of c programming in notes for students .pptx
top salesforce developer skills in 2025.pdf
Digital Systems & Binary Numbers (comprehensive )
Designing Intelligence for the Shop Floor.pdf
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
Design an Analysis of Algorithms I-SECS-1021-03
Adobe Premiere Pro 2025 (v24.5.0.057) Crack free
EN-Survey-Report-SAP-LeanIX-EA-Insights-2025.pdf
SAP S4 Hana Brochure 3 (PTS SYSTEMS AND SOLUTIONS)
Introduction to Artificial Intelligence
Nekopoi APK 2025 free lastest update
Embracing Complexity in Serverless! GOTO Serverless Bengaluru
CHAPTER 2 - PM Management and IT Context
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf

Microservices interaction at scale using Apache Kafka

Editor's Notes

  • #3: майже 2 роки на апворку на апворку можна заробляти, навіть якщо ваш замовник - сам апворк деколи пишу статті, на своєму сайті, заходьте, підписуйтесь
  • #6: Почнемо з ревью … Ідея зрозуміла, ви маєте систему, яка працює в межах одного процесу… Така система з часом виростає … І однією з форм еволюції такої системи є перехід на мікросервісну … В теорії, ви берете вашу монолітну однопроцесну систему, і розбиваєте її на багато - багато сервісів. В вас буде окрема команда В вас буде окремий деплоймент Це все - чиста теорія.
  • #7: Реальність виглядає ось так. По-перше, переважно, такі мікросервіси - динамічні, з постійно змінюваною адресою в інтернеті. Якщо вони не динамічні, тоді це не ті мікросервіси, які я знаю. По друге, таких сервісів багато, всі вони різні, по різному працюють, і мають різні дані. І останнє, це різні команди, різні підходи, різні думки. Це вносить корективи загалом.
  • #8: Щоб ще більше розвіяти картину, пропоную подивитись скільки їх може бути. Амазон і Нетфлікс, компанії - гіганти, які одні з перших впровадили мікросервісну архітектуру. Подивіться скільки в них сервісів.
  • #9: Які ж цілі потрібно ставити в мікросервісній архітектурі ?
  • #10: Перш за все, це скейлінг в термінах інженерів і спеціалістів. Як я вже казав, в вас будуть великі і маленькі сервіси, так от для великих …
  • #11: Також, скейлінг в межах даних. Якщо ваша організація переходить чи будує мікросервісну архітектуру, то даних в вас буде ну дуже багато. І дані ці будуть різні. І так як на сьогоднішній день ми маємо багато різних стореджів, ми можемо вибирати. Для графових даних нам… Якщо маєте пошукову логіку - Якщо в вас не стабільна схема, не підходить реляційна структура, то …
  • #12: І напевно, найголовніше, ви хочете бути незалежними. Незалежними від інших сервісів. Згадайте ту картинку з амазоном і нетфліксом і подумайте скільки людей працює там. В мікросервісах, такій команді потрібна незалежність, можливість працювати і не вклинюватись в інші команди. Така команда буде мати окремі мітинги, окремий пленінг, окремий кодбекс, деплоймент.
  • #13: Але компанії, так чи інакше, це колекції аплікацій, модулів, підсистем, які повинні працювати разом в якійсь степені, щоб досягти одного спільного результату. Іншими словами, їм потрібно комунікувати. Працюючи в моноліті, ви над цим не задумувались, оскільки це була одна аплікація. Так само і тут, маючи незалежні, окремі сервіси, які бігають по мережі, мають різні бази даних і пишуться окремими командами, їм теж потрібно комунікувати. Які існують патерни комунікації ?
  • #14: Перший і найгірший патерн - патерн шареної бази даних. Ідея полягає в тому, що всі, чи декілька сервісів використовують одну базу даних. Такий патерн можна ще назвати розподіленим монолітом, оскільки в довгостроковій перспективі ви нічого не вирішуєте. Все лишається те ж, що і в моноліті, тільки сервіси тепер бігають по мережі.
  • #15: Я довго думав як зобразити цей патерн, і знайшов цей твіт, який класно описує весь сюр, який трапляється при такому підході. Всі команди завязані на одну базу, комунікують теж через неї. При рості навантаження росте і база. З часом виростає в дуже велику. А чи всім сервісам потрібна така база ?
  • #16: Загальне правило - мати одну базу на один сервіс. Ситуація може мінятись від сервісу до сервісу, але ідея зрозуміла - чим більше команд працюють в одній базі даних, тим складніше її підтримувати і тим вона стає більша. Саме тому найкраще одній команді для одного сервісу мати одну базу даних.
  • #17: Ок, якщо не шарена база, то що ? Ми живемо в світі API і ендпоінтів. Їх потрібно написати, версіонувати, підтримувати. Це потрібно сусідньому сервісу, не вам. Створює real time coupling
  • #18: Не треба забувати, що сервіси не рівні між собою. І якщо більший сервіс викликає меншого - менший може просто завалитись.
  • #19: Інша річ, що не всі сервіси мають бути частиною критичного шляху, який повинен пройти ріквест перед тим, як віддати відповідь. Просто тому, що вам не потрібно робити все зразу. Створюючи якусь покупку і відправляючи запит в OrderService, ви напевно не захочете в ту ж хвилину відправляти запит в Shipping Service, щоб оформити трекінг код. Просто тому, що ваш домен так не працює. І Це створює додаткове лейтенсі, що негативно скажеться на продукті, який ви розробляєте.
  • #20: І навіть, якщо б вам потрібно було виконати все і зразу, за допомогою апішок чи ендпоінтів, ви б не зробили достатньо якісно. Якщо під час виконання цього шляху щось завалиться, а щось вже виконається, що тоді ? Двох фазний коміт CAP теорема
  • #21: І коли ми говорили про те, що комунікація за допомогою сервісних інтерфейсів звязує сервіси докупи, то пофіксити це можна за допомогою третьої сторони: замість того, щоб відправляти повідомлення між сервісами напряму, ми це зробимо за допомогою якогось меседж брокера, який, в доповненні до всього, це ж саме повідомлення може відправити і іншим сервісам, якщо їм це буде потрібно.
  • #22: Таким чином, виходить, що в нас буде два типи даних - дані, які ми будемо тримати в конкретному сервісі для того, щоб видавати цю інформацію в зовнішній світ, і дані, які будуть бігати через меседж брокер, і які будь який сервіс зможе прочитати.
  • #23: Такий підхід до комунікації створює більшу координацію і дозволяє новим сервісам створюватись і заходити на платформу без ніяких проблем.
  • #24: І кафка якраз є той меседж брокер, який буде відправляти зберігати ці повідомлення і відправляти їх всім охочим. За останні роки дала про себе знати, сьогодні Кафка - це технологія, яка дозволить принести комунікацію між вашими сервісами на новий рівень.
  • #28: Окей, а як реально можна застосувати Кафку в мікросервісній архітектурі ? Я виділив три приклади, при яких Кафка може бути дуже корисна
  • #29: Перше, Івент Сорсінг. Архітектурний підхід, який говорить нам, що стан системи визначається послідним ланцюжком подій. Таким чином, кожна зміна даних логується і зберігається.
  • #30: Візьмемо приклад. В нас є ріквест, який модифікує дані в одному сервісі, і ріквест, який читає якусь інформацію, в іншому сервісі. Як другому сервісі отримати інформацію з першого сервісу ? Можливо, комусь стало цікаво - а як же перший мікросервіс зберігає інформацію. Одна з хороших якостей івент сорсінгу полягає в тому, що мікросервіс 1 зберігає інформацію за таким ж принципом.
  • #31: І коли говорять про івент сорсінг системи, не можна не згадати такий патерн, як CQRS. Цей патерн часто використовують в звязці з event sourcing системами. Ідея в тому, що в вас є дві різні моделі для запису і для читання даних. Є багато різних думок з приводу цього підходу, є багато різних думок з приводу нього, і єдине, чому я згадав цей патерн - це тому, що він може нам дати відповідь на питання як організувати структуру таких сервісів.
  • #32: Перш за все, сервіс, який буде приймати write запити За ним слідує сервіс, який буде буде виступати в ролі івент хендлера і третій - інстанс, який буде читати дані з рід бази.
  • #33: Вьюшки і Сторед процедури
  • #34: Event sourcing не для всіх.
  • #35: Хто чув про цей підхід ???
  • #36: Почнемо з прикладу. В нас є якийсь сервіс, який повинен записати інформацію в базу, апдейтнути кеш, і зробити реіндекс в серш. І традиційно, ми послідовно записуємо інформацію спочатку в базу, потім в кеш, потім в серч інжин. Хто бачить в цьому якусь проблему ? Проблема в тому, що три сорси даних не можливо постійно апдейтити так, щоб не мати частковий фейлурів
  • #37: І коли ми говоримо про CDC, то нам потрібно і далі писати в базу, але не писати в Cache і Search Index. На сьогоднішній день, практично всі бази, які в більшій чи меншій мірі активно юзаються, мають можливість читати так званий Write Ahead Log змін, які відбуваються в базі. В Постгресі це можливо за допомогою Logical Decoding фічі, в MySQL є BinLog, в Oracle Golden Gate і навітьв в монго це можна зробити за допомогою OpLog-а. І зприходом хороших якісних меседжінг систем це стало особливо актуально, оскільки це дозволяє писати в базу, і з бази паралельно записувати в меседжінг систему.
  • #39: В Вас Напевно буде стара логіка Замість того, щоб читати з бази, краще стрімити ці зміни.
  • #42: Event sourcing не для всіх.
  • #46: Event sourcing не для всіх.
  • #54: В Кафці є можливість розміщувати консюмери в межах консюмер групи. В такій консюмер групі, один партишин буде читати один і тільки один консюмер. Приклад Ця ідея consumer груп класно мапиться на мікросервіси
  • #55: Оскільки консюмери можуть самі вибирати, з якого порядку місця читати повідомлення,
  • #56: Паттерн Checkpoint. В Кафці все відбувається по інакшому, так як повідомленя постійно стираються
  • #57: Кейси з мікросервісів, коли це корисно Так як лог нікуди не дівається, ми можемо використовувати як source of truth
  • #58: at least once retries at most once
  • #59: at least once retries at most once
  • #70: Висновок звідси http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/