I’m surprised more languages haven’t provided such an operator. However it grates against the default imperative nature of languages. Take a AND expression, for instance. The AND expression should really only be satisfied when the left and right expressions are available and each of those expressions could be running in parallel. You can only get close to this in popular languages using async/await but should really be more primitive than that. Bring on proper reactive languages!
Great talk. How does one track what is going on 'overall' and if there are any issues? Assuming we write these reactive services around customer journey/stories ("use-cases") - and we end up splitting processing of various steps of the journey amongst several reactive microservices (at some well-considered appropriate level of granularity). Now how best do we track, say a user transaction for use-case A, which had 4 stages to be processed by 4 different reactive microservices - at which stage the processing is at the moment for the user? How many such transactions completed (and at what rate - as ultimately the customer may care about overall latency in processing her requests)? How many are in what stage? Is the stream processing going smoothly at some desired rate? Is there a bottleneck developing? "What is going on in my system"?
I would say with structured log events. It’s a good fit as many of your questions related to operational views of system health. Given you are logging the right fact, you could build some useful dashboards in Kibana, Graphana or Seq.
Scalable, distributed workflows can be done using two different patterns - orchestration and choreography. Orchestration is easier because each transaction has a central orchestrator that manages the flow, implements retry logic, and deals with failure conditions using semantic backout logic. The downside is that it tends to tightly couple the services together. Choreography is loosely coupled, but it is much more complicated because each service manages its own rules. Specifically, the service that owns a specific piece of data owns the rules for that data. My view is that services need to emit failures (customer X changed failed) in addition to update successes (customer X changed). Other services need to subscribe to those error events and act appropriately. If you need a single view of a "transaction" you can have a state service that subscribes to the global event stream and projects those events into a current state for each transaction.
