Ben Stopford is an engineer and architect working on the Apache Kafka Core Team at Confluent (the company behind Apache Kafka). A specialist in data, both from a technology and an organizational perspective, Ben previously spent five years leading data integration at a large investment bank, using a central streaming database. His earlier career spanned a variety of projects at Thoughtworks and UK-based enterprise companies. He writes at Benstopford.com.
19. Single Sign On Business Serviceauthorise(),
It’s unlikely that a Business
Service would need the
internal SSO state /
function to change
Single Sign On
26. Service Database
Data on
inside
Data on
outside
Data on
inside
Data on
outside
Interface
hides data
Interface
amplifies
data
Databases amplify the data they hold
28. Service Database
Data on
inside
Data on
outside
Data on
inside
Data on
outside
Encapsulation
protects us
against future
change.
Databases
provide ultimate
flexibility for the
now
These approaches serve different goals
37. Nice neat
services
Service
contract too
limiting
Can we change
both services
together, easily?
NO
Broaden Contract
Eek $$$
NO
YES
Is it a
shared
Database?
Frack it!
Just give me
ALL the data
Data diverges.
(many different
versions of the same
facts)
Lets encapsulate
Lets centralise
to one copy
YES
Start
here
Cycle of inadequacy:
38. These forces compete in
the systems we build
Divergence
Accessibility
Encapsulation
45. Event Driven + CQRS +
Stateful Stream Processing
Orders
Service
Stock
Service
Orders
Fulfilment
Service
UI
Service
Fraud
Service
•  Events form a central Shared
Narrative
•  Writes/Commands => Go to “owning”
service
•  Reads/Queries => Wholly owned by
each Service
•  Stream processing toolkit
49. Kafka is a type of messaging system
Writers Kafka Readers
Important Properties:
•  Petabytes of data
•  Scales out linearly
•  Built in fault tolerance
•  Log can be replayed
61. Stateful Stream Processing adds
Tables & Local State
stream
Compacted
stream
Join
Stream Data
Stream-Tabular
Data
Domain Logic
Tables
/
Views
Kafka
Event Driven Service
62. Avg(o.time – p.time)
From orders, payment, user
Group by user.region
over 1 day window
emitting every second
Stateful Stream Processing
Streams
Stream Processing Engine
Derived “Table”
Table
Domain Logic
63. Tools make it easy to join streams
of events (or tables of data) from
different services
Email Service
Legacy App
Orders Payments Stock
KSTREAMS
Kafka
64. So we might join two event
streams and create a local
store in our own Domain Model
Orders
Service
Payment
Events
Purchase
Events
PurchasePayments
65. Make the projections queryable
Orders
Service
Kafka
Queryable State API
Context
Boundary
66. Blend the concepts of services
communicating and services sharing state
customer orders
catalogue
Pay-
ments
67. Very different to sharing a database
customer orders
catalogue
Pay-
ments
Services communicate and
share data via the log
Slicing & Dicing is embedded in each
bounded context
69. Easy to drop out to an
external database if needed
DB of choice
Kafka
Connect
APIFraud
Service
Context
Boundary
70. Oracle
Connector API & Open Source Ecosystem
make this easier
The Log
ConnectorConnector
Producer Consumer
Streaming Engine
Cassandra
71. WIRED Principals
•  Wimpy: Start simple, lightweight and fault tolerant.
•  Immutable: Build a retentive, shared narrative.
•  Reactive: Leverage Asynchronicity. Focus on the now.
•  Evolutionary: Use only the data you need today.
•  Decentralized: Receiver driven. Coordination avoiding. No
God services