cqrs   3024

« earlier    

Build Services on a Backbone of Events | Confluent for Microservices
Excellent. Great diagram showing event driven approach to placing an order.

"There are three advantages of this ‘Query by Event-Carried State Transfer’ approach:

* Better decoupling: Queries are local. They involve no cross-context calls. This ties services far less tightly than their request-driven brethren.
* Better autonomy: The Orders service has a private copy of the Stock dataset so it can do whatever it likes with it, rather than being limited to the query functionality offered by the Stock Service.
* Efficient Joins: If we were to “look up the stock” on every order, we would effectively be doing a join over the network between the two services. As workloads grow, or more sources need to be combined, this can be increasingly arduous. ‘Query by Event Carried State Transfer’ solves this issue by bringing queries (and joins) local.

This approach isn’t without its downsides though. Services become inherently stateful. They need to keep track of, and curate, the propagated data set over time. The duplication of state can also make some problems harder to reason about (how do we decrement the stock count atomically?) and we should be careful of divergence over time. But all these issues have workable solutions, they just need a little consideration. This is well worth the effort for larger, more complex estates. "

"*A bounded context, here, is a set of services which share the same deployment cycle or domain model."

"To limit the scope of remote queries we can use a clustered context pattern. Here event flows are the sole communication pattern between contexts. But services within a context leverage both event-driven processing and request-driven views, where they are needed."

"In the code example here, the ID is used to tie the two together. So you write an Order with ID=5. If you immediately send a read request for ID=5, if it doesn’t exist in the view, the view will block until order 5 is available or the call times out. This assumes orders have unique ids (or ids are versioned)."

"You shouldn’t have to use individual consumer groups. So long as you key the request by a request ID or correlation ID then the response will come back to the same node that sent it (with all nodes in the same consumer group) – so you shouldn’t need a distributed cache, local one is fine. If there is a rebalance for any reason you could get timeouts but that’s usually fine.

Note the use of the KStreams metastore to reroute requests to their key owner:

"The schema registry provides details of what events are published on what topics. Confluent will be releasing a better UI for this in the future which includes the ability to search schemas etc. But the best way to manage schemas today is actually in github. This provies a repo of available event schemas, you can propose changes to those events and have your downstream consumers +1 them. Consumers can also propose PRs for things they need."

"Decoupling: Break long chains of blocking commands. Decompose synchronous workflows. Brokers decouple services so it’s easier to plug new ones in, or change those that are there.
Offline/Async flows: When the user clicks a button many things happen. Some synchronously, some asynchronously. Design for the latter and the former falls out for free.
State Transfer: event become the dataset of your system. Streams provide an efficient mechanism for distributing datasets, so they can be reconstituted, and queried, inside a bounded context.
Joins: It’s easier to combine/join/augment datasets from different services. Joins are fast and local.
Traceability: It’s easier to debug the distributed ‘murder mystery’ when there’s a central, immutable, retentive narrative journaling each interaction as it unfolds in time."
eventsourcing  streaming  kafka  microservice  DistributedSystems  WebSockets  AsyncUI  CQRS  EventCarriedStateTransfer  boundedcontext 
yesterday by colin.jack

« earlier    

related tags

amazon_aws_aurora  amazon_aws_sqs  application-services  arc  architecture  asp.net  asynchronous  asyncui  aws  awslambda  boilerplate  books  boundedcontext  buy  cache  cap  clojure  cloud  command  concurrency  conference  conflicts  confluent  core  crux  csharp  database  ddd  design-patterns  design  development  discussion  distributed  distributedsystems  domain-driven-design  elixir  es  evening  event-driven  event-sourcing  event.sourcing  event  event_sourcing  eventcarriedstatetransfer  eventing  events  eventsourcing  go_tr  iot  java  javascript  kafka-streams  kafka  latency  later  materialized-view  messaging  microservice  microservices  microsoft  mvc  mysql  node.js  nodejs  opinion  orleans  overview  pattern  patterns  presentation  programming  projections  reference  rx  scalability  serverless  shared  slides  sns  software  softwaredevelopment  source  sourced  sourcing  specification-pattern  spring  sqs  strangeloop  streaming  swa  testing  tr-2019-02  training  transaction  tutorial  typescript  udi-dahan  video  web  websockets 

Copy this bookmark: