• Hold on! Your updates are spamming me (28 September 2021)
    Sending notifications to users might be easy. Dealing with a lot of messages can result in spamming them. How can we evolve a simple notification infrastructure to avoid delivering too many messages?
  • There is no such thing as orchestration (8 July 2021)
    Coupling is subtle and sneaks in from every hole. With long-running business processes, the overall business problem tends to take precedence over what seems to be a minor concern. Unfortunately, those choices might turn against us in the long run.
  • Got the time (5 March 2021)
    When modeling time, we can use a batch job-oriented approach, or what I like to call the ticking time bomb model. Or we can flip the responsibilities and use messages for our future selves to achieve the results more efficiently and effectively. Let's see how to model time using NServiceBus sagas and messages.
  • I'll be back (8 February 2021)
    Time from the perspective of systems design has many nuances and complexities. There are clock drift issues and design issues related to modeling the passage of time. Shall we model the passage of time as a clock does?
  • Transactions? None for me, thanks (30 January 2021)
    Queues are designed for reliability. I personally stress a lot about designing message processing to be as transactional as possible. Is there a use case for unreliable message processing?
  • The case of NServiceBus long running jobs: OCR Processing. (20 December 2016)
    Designing systems using a message based architecture is awesome. Messages are a nice way to design human interactions and to model how different components in a domain interact with each other. Unfortunately, technology sometimes causes more headaches than needed. And when it comes to messaging, long running jobs are a interesting headache to deal with.
  • NServiceBus batch processing with Sagas. (7 September 2016)
    We have already seen how to consume, or simulate that, messages in batches. We might have a different use case, from the one outlined in the previous post, money transactions processing.