Please enable JavaScript.
Coggle requires JavaScript to display documents.
12 Event Driven Systems Book Part 2 - Coggle Diagram
12 Event Driven Systems
Book Part 2
Availability
You're only as available as the sum of your dependencies.
Break down the synchronous ties that bind services together using
(a) asynchronicity and (b) a message broker as an intermediary.
Orchestrated and Choreographed
Advantage of orchestration is that the whole workflow is written down, in code, in one place. That makes it easy to reason about the system. The downside is that the model is tightly coupled to the controller, so broadly speaking choreographed approaches better suit larger implementations (particularly those that span teams and hence change independently of one another).
5.7 (Page 40)
Event
Notification and
maps to stateless stream processing,
Event-carried state transfer
(Replication duality)
maps to stateful stream processing
Communication between micro services needs to be based on asynchronous message passing (while logic inside each micro service is performed in a synchronous fashion).
Typical Mixed architecture -
REST with Event (Fig 5.9)
Reasonably sized architectures it is sensible to blend request- and event-based protocols,
Domain-driven design (DDD)
Confines reuse within a bounded context,
Example?
Replayable logs
Ops engineers => Faster to troubleshoot issue
Comparison
An event-driven application uses a single input stream to drive its work.
A streaming application blends one or more input streams into one or more output streams.
A stateful streaming application also recasts streams to tables (used to do enrichments) and stores intermediary state in the log, so it internalizes all the data it needs.
Event Sourcing
comprehensive audit of exactly what the system did.
Re-derive the current state of the system
by rewinding the log and replaying the events in order.
Event Sourcing ensures that the state a service communicates and the state a service saves internally are the same.
Command Query Response Segregation (CQRS) [Fig 7.1]
Command Sourcing
Query
Materialized view
A table that contains the results of some predefined query, with the view being updated every time any of the underlying tables change.
Event Streams as a
Shared Source of Truth
you can have as many different as many need.
Each is focused on the use case at hand.
Database
no “one-size-fits-all” approach
A supplementary benefit of using CQRS is that a single write model can push data into many read models or materialized views. So your read model can be in any database, or even a range of different databases.
Events should be modeled as whole facts (a whole order, in its entirety) or as deltas
Rule of thumb is record
exactly what you receive, immutably.
Kafka ships with two different APIs
Connect API
Streams API
Contain a simple embedded
database, called a state store.