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

  1. Notification and
  1. Event-carried state transfer
    (Replication duality)

maps to stateless stream processing,

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)

Domain-driven design (DDD)

Confines reuse within a bounded context,

Reasonably sized architectures it is sensible to blend request- and event-based protocols,

Replayable logs

Ops engineers => Faster to troubleshoot issue

Comparison

  1. An event-driven application uses a single input stream to drive its work.
  1. A streaming application blends one or more input streams into one or more output streams.
  1. 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.
  1. 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.

  1. Command Query Response Segregation (CQRS) [Fig 7.1]
  1. Command Sourcing
  1. Query

Event Sourcing ensures that the state a service communicates and the state a service saves internally are the same.

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

  1. Connect API
  1. Streams API

Contain a simple embedded
database, called a state store.

Example?