Orchestrating processes for fun and profit


I’ve already shown here that with some trickery you can write orchestrations in C# based on async-await. It’s time to revisit this idea, now with a custom orchestration of mine.

Show me the code!

The orchestration is based on the event sourcing infrastructure built by me. This project is not public (yet) but it’s similar to any other ES library. The main idea behind building an orchestration on top of it is that state changes of an orchestration are easily captured as events like: GuidGenerated, CallRecorded, UtcDateTimeObtained, etc etc. If this is the case, we could model any orchestration as an event-sourced aggregate.

Here it is an example of reserving a trip, that needs to coordinate between reserving a hotel and a flight. Additionally a few calls were added to just show what the orchestration is capable of


  • Line 19: orchestration can delay it’s execution. It does not mean that it will stay in memory for that long. It will record the need of delay to be woken up when the time comes
  • Line 22: when a Guid is generated with Orchestration.NewGuid it means that it will have the same value when the orchestration is executed again. Process dies and the orchestration is executed elsewhere? Don’t you worry, the guid value has been recorded
  • Line 25: same with dates
  • Line 28: an external call to any system. Here, we try to ReserveHotel. 3 attempts are made with a exponential back off. Between calls, if the configured timespan is long enough, saga can be swapped from memory (like with Delay)
  • Line 33: same as with hotel
  • Line 38: the compensation part

Execute it!

The execution would take the persisted events and replay them if process failed, machine died, etc. on another host. Because before every external call, all the recorded events are persisted, it ensures that even during a rerun, all the values will be exactly the same and calls that were already made won’t be made again.


Orchestrating with async-await trickery is much easier and can be written in a dense, simple way of a regular method call. Having an event-sourced foundation makes it even easier as you can use already existing pieces and persist all orchestration events as event of some kind of aggregate.

How to steal customers from your competitors


I’ve seen this pattern more than a few times during last few years. It looks that the approach I describe below is quite handy when trying to steal clients from your competitors in IT landscape.

I look the same but I’m better

Have you heard that you can use MongoDB driver to connect to Azure DocumentDB? Just like that one can easily swap it’s database and use DocumentDB without changing a line of its code. If your app weren’t cloud native and as one of the strategies you were considering was running MongoDB on your own in the cloud, you don’t have to do it any longer. You can use this offering of the Database as a Service and simply make your app cloud-ready in a matter of seconds (just change the connection string).

Have you heard about the ScyllaDB? It’s a functional port of Cassandra database. It’s  was written in C++ with a custom SEDA-like architecture, user-level network drivers and a lot of understanding of the mechanical sympathy. How does it work? It supports the same network protocol, it supports the same file structure on your disk. Does it look similar? Yes, you can use it as a drop-in replacement. No migrations, not a single line of your code rewritten. Isn’t it great?

API parity, feature parity

It’s often said that the feature parity can hurt your business. If you can be compared you will be compared to others and eventually, the better/cheaper will win. What about API parity? What about ScallaDB that can support the same workload on 10x smaller number of servers? What about DocumentDB that is served as a service and additionally has its amazing indexing algorithm? They strive for this comparison, especially when they guarantee no-op switch using not the feature parity but the API parity.


Mimicking and setting free customers from a vendor lock-in looks like an interesting and valuable vector of attack for products that offer something more, under the same layer of API. I think, that especially in the public cloud sector, we’ll see it more and more.