Converging processes


Completing an order is not an easy process. A payment gateway may not accept payments for some time. A coffee can be spilled all over the book you ordered and a new one needs to be taken from a storage. Failures may occur in different moments of the pipeline, but still your ordered is received. Is it a one process or multiple? If one, does anyone takes every single piece into consideration? How to ensure that eventually a client will get their product shipped?

Process managers and sagas

There are two terms used for these processors/processes. They are process managers and sagas. I don’t want to go through the differences and marketing behind using one or another. I want you to focus on a process that handles an order and that reacts to three events:

  • PaymentTimedOut – occurring when the response for Payment was not delivered before the specific timeout
  • PaymentReceived – the payment was received in time
  • OrderCancelled – the order for which we requested this payment was cancelled

What messages will this process receive and in which order? Before answering, take into consideration:

  • the scheduling system that is used to dispatch timeouts,
  • the external gateway system (that has its own SLA),
  • messaging infrastructure

What’s the order then? Is there a predefined one? For sure there isn’t.


Your aim is to provide a convergent process. You should review all the permutations of the process inputs. Being given 3 types of input, you should consider 3! = 6 possibilities. That’s why building a few processes instead of one is easier. You can think of them as sub-state machines that later, can be composed into a bigger whole. This isn’t only a code complexity, but a real mental overhead that you need to design against.


Designing multiple small processes as sub-state machines is easier. When dealing with many events to react to, try to extract smaller state machines and aggregate them on a higher level.


Year 2016 in .NET ecosystem


This was a truly amazing year for .NET ecosystem. Let’s go through some of the important events in our ecosystem.

Core & Standard

.NET Core and Standard moved closer to the mainstream development. There are applications running Core in production already. The Standard addresses the fragile point of the cross platform solutions – APIs which you can use. It had some versioning problems, but they seem to be solved for now.


The ASP team with Ben A Adams are working really hard! ASP .NET Core, on Linux, is 10th in the ranking of the plain text speed. Let me say it again: Linux, .NET Core, 10th place. And it will be faster for sure.

Slices, memory pools and more

.NET Core and .NET at all are getting more and more attention in terms of performance. Slices (previously spans) which can be seen as a better alternative to ArraySegment abstracting access to an allocated collection of values (an array, an unsafe pointer-based memory segment). Memory pools and UTF8 strings are being brought to the mainstream. This won’t be used in every project, but having these foundations is much easier to think about .NET as a platform for writing well performing systems, databases etc.


BenchmarkingDotNet isn’t a library used only occasionally. Many projects embed tests based on it as a part of their tests suites. You can see the benchmarking output table in many PRs which is really good. I’ve heard Knuth’s phrase about performance much to often. It’s good to see that performance is getting attention. You don’t have to benchmark everything, but as a software engineer you should be aware of the tooling and apply it when needed.


Async await is globally accepted. The understanding of it seems to be better. Hopefully, we’ll see less of the sync/async battles and new APIs will follow only one of these.


It was a really good year. Let’s push it even further in the next one!

Why persistent memory will change your world


If you haven’t heard, the non volatile RAM memory is coming to town and for sure will change the persistence patterns of databases, queues, loggers. Want to know more about this new wave of hardware? Read along.


The first and the most important aspect is that persistent memory on Windows, reuses already existing APIs. First, if you want to use the drive just as a block storage, you can do it. You’ll be able to create files, write them etc. There’s another way of using it, which is much faster, called DAX.

The direct access enables to use the non volatile memory directly. What do I mean by directly? I mean accessing the memory with a raw pointer. How do you obtain a pointer? The old fashioned memory mapped file API is used. First, create a file, then map it and here it is! No FlushFileBuffers, no fsync. Just a raw pointer to the memory. Can you imagine writing to a mapped file and just having it persisted?


The non volatile memory is really fast. You can write 4GB per second. Yes, it’s 4GB per second of a persistent memory. The latency is extremely low. It’s so low, that using any form of asynchronous programming (raw completion ports, async-await) brings more havoc than just waiting for having this memory written. Yes, this means that your methods hitting files mem mapped with DAX will not need async signatures. Of course you’ll be able to preserve them just for the compatibility.

Ordering matters

It looks like tech heaven. No more data loss during power outages, right? It’s not entirely true. The persistent memory acts as a memory. There is an order of execution in which data are transported there. Imagine now writing the following string:


If power went down after copying first three letters you’d be left with


Which although shows the same attitude, is not what we wish for when thinking about persistence. This example shows, that good old fashioned IO access patterns will still be important, like write-ahead logging or copy-on-write. But let me remind you again, they will be free with no synchronization, no flushing required.


The persistent memory will change the world. SQL Server 2016 has already adopted it, as you can see here. Some databases are already there, like LMDB using memory mapped files (same API for the win!) with an ability to run as non-durable. Guess what. Now it’s durable. More databases will follow.


The persistent memory is here. You won’t probably rewrite or rethink your application as majority of apps do not deal with IO directly, but just by applying it to your database or other IO bound systems will be a real game changer.

Cel: MVP


To będzie krótki post. Po spojrzeniu na moją aktywność w roku 2016 postanowiłem zgłosić swoją kandydaturę na MVP w kategorii Visual Studio and Development Technologies. Wiem, że to dopiero październik i wcześnie na podsumowania, ale biorąc pod uwagę liczbę prezentacji, kontrybucji do projektów Open Source, zorganizowanych spotkań Warszawskiej Grupy .NET i postów na tym blogu stwierdzam, że nastał czas na zgłoszenie się. Link do strony do zgłaszania nominacji znajduje się tutaj: Możesz użyć go, aby zgłosić mnie raz jeszcze. Mój email to

Czasami programujemy w parach, dlaczego więc nie zgłaszać kandydatur parami? Dodatkowo poza mną zgłosiłem Konrada Kokosę. Znacie go dobrze z prezentacji i bloga dotyczącego performance’u i pamięci. Więcej o jego kandydaturze możesz przeczytać tutaj.


It will be a short entry. After looking at my activities in 2016 I decided to nominate myself for the MVP award in Visual Studio and Development Technologies. I know it’s quite early to summarize a whole year, but considering number of talks, contributions to Open Source projects, meetings of Warsaw .NET User Group and posts on this blog I can tell that it’s the right time to make it. You can use following link to nominate a person and you can use it to nominate me once again.

Sometimes we program in pairs, sometimes we nominate in pairs. That’s why I nominated Konrad Kokosa. You can read about his candidature more here.

Motivation is nothing

Grit is everything

For sure you saw it before, a person gets motivated to do something. Whether they attended a conference, or saw a video how to do 100 push ups under 1 minute. The thing is that the source of this motivation is external and is just an impulse. It may encourage one to get involved but it won’t help to maintain the habit. I’d say, that you GET motivated sometimes, but you AREN’T motivated all the time. It’s so important to make the next step and see, that to really make something you need perseverance, you need persistence, you need a plan. If you exercise EVERY work day, that’s a totally different than exercising A LOT. The first is a plan, the other is try-to-follow-plan.

Not all-in-1
Remember one thing. If you want to change your life, you can’t do it at once, but rather, you should pick a thing and stick to it. Focus on one thing, make it a habit and move on. With this approach, you can build up a big mental muscle that will help you with next aims. To give you an example I stopped eating sweets and sugar over 1 month ago (this seemed impossible to me).

Mastering one thing at a time isn’t my idea and it has been proven in various cases.

Grit becomes a very popular topic. Don’t just get motivated to learn it some day 😉

Build Tour 2016 in Warsaw

Probably every .NET developer watched at least a few presentations from the Build conference. Happily for Polish .NET developers, Warsaw has been selected as one of the cities where Build speakers came to share their exciting news about Microsoft, Windows and .NET.

The conference took place in Expo XXI. The very first thing were containers with Build logo on them. I must admit that this was a bold way of showing where the conference takes place and much better than just a few stands. The venue and the scene were amazing. It was a copy of the Build scene so you could feel the atmosphere. Every organizational aspect of it was well thought through.

The key topics were Universal Windows Platform apps, Web Apps and IoT. Even if I don’t work with these on daily basis the level of talks, as well as the way they were being presented, was balanced enough to actually show and share some meaningful information. The top three for me were:

  1. The packing of Universal Windows Platform apps. Running an installer in a recording container to be able to apply all the operations on the system later on.
  2. Manifoldjs for building hosted we apps.
  3. Enhanced Reality provided with the Unity engine.

It was quite sad that people started leaving quite early. Fortunately, a solid group (including me:P) stayed till the very end when a networking took place. I’m looking forward to seeing Build 2017 again. Of course, in Warsaw.

Single producer single consumer optimizations

The producer-consumer relationship is one of the most fundamental cooperation patterns. Some components produce values, issues requests and some consume/handle them. Depending on the number of components at the end of this dependency it’s called ‘single/multi producer single/multi consumer’ relationship. It’s important to make this choice explicit, because as with every explicit choice, it enables some optimizations. I’d like to share some thoughts o the optimizations taken in the single consumer single producer scenario in the RampUp library provided by OneToOneRingBuffer.

The behavior of ring buffers in RampUp is ported from Java’s Agrona. They provide a queue that enables reading sequentially on the consumer side. The reasoning behind it is that sequential reads are CPU friendly, so that consumer can process messages much quicker. For ManyToOneRingBuffer the production part is quite complex. It proceeds as follows:

  1. check against the consumer position, is there enough of space
  2. allocate a slot in the ring (this is done with Interlocked operations, in a loop, may take a while)
  3. write a header in an ordered way (using volatile)
  4. put data
  5. write the header again marking the message as published

This brings a lot of unneeded work for a single producer. When considering a single producer, there’s nothing to compete with. The only check that needs to be made is that the producer does not overlap with the consumer. So the algorithm looks as follows:


  1. check against the consumer position, is there enough of space
  2. put data
  3. write the header again marking the message as published
  4. write the tail value for future writes

Removal of Interlocked and lowering the number of Volatile operations can improve the producer performance greatly (less synchronization).


If you wanted to compare these two on your own, here you are: ManyToOne and OneToOne.

Happy producing (and consuming).