Posts related to messaging

RPC vs. Messaging – which is faster?

Sometimes developers only care about speed. Ignoring all the other advantages messaging has, they’ll ask us the following question:

“But isn’t RPC faster than messaging?”

In place of RPC, ¹ they may substitute a different term or technology like REST, microservices, gRPC, WCF, Java RMI, etc. However, no matter the specific word used, the meaning is the same: remote method calls over HTTP. So we’ll just use “RPC” for short.

Some will claim that any type of RPC communication ends up being faster (meaning it has lower latency) than any equivalent invocation using asynchronous messaging. But the answer isn’t that simple. It’s less of an apples-to-oranges comparison and more like apples-to-orange-sherbet.

Let’s take a look at the bigger picture.

Cross-platform integration with NServiceBus native message processing

When the Romans met the Gauls for the first time, they couldn’t talk to each other. The Romans spoke Latin, and Gauls a Celtic language. How could they communicate? It must have been difficult to start with simple gestures, slowly building enough concepts, until a full translation guide was possible. Perhaps one day, as in Star Trek, a universal translator will enable us to talk to anyone regardless of their language, even if chah jatlh Tlhingan. ¹

Sometimes I feel like a Roman meeting a Gaul for the first time. Different technologies make sense to address different problems. For example, if your order entry front end can benefit from rapid prototyping, you should be able to use Ruby on Rails and Active Record. In your back-end system, you might benefit from event-driven architecture, automatic message retries, and orchestration of long-running business processes. In that case, you should be able to use C#, RabbitMQ, and a messaging framework like NServiceBus.

But then, how do we get these parts to communicate and work together?

Autosave for your business

If you’re a long-time video game player like me, your muscle-memory vividly remembers the F5 key’s location on your keyboard. For everyone else: F5 is a common key-binding for “quicksave” in computer-games. And like many others, I learned how to use it the hard way. After spending hours sneaking through dungeons, battling orcs, and looting valuable treasures, some nasty troll made an unexpectedly quick end to my character. That’s when I would realize that I hadn’t saved my game for a very long time and had to start over. From that moment on, I’d save my game as often as I could, and F5 became my closest ally.

Modern games now provide a built-in feature called autosave. These games save your progress automatically now and then so that you won’t lose all your progress—only a few minutes at worst. This might sound trivial and obvious, but it is a game-changer for player experience. The player can now focus on solving their mission rather than the mechanics of the game itself.

Why are we talking about video games when we have important business (let’s say, selling video games) to do? Let me ask a different question: what if that nasty end boss doesn’t come in the form of a troll? What if the end boss is a network error, power outage, concurrency conflict, or even squirrels?

What Starbucks can teach us about software scalability

In 2004, Gregor Hohpe published his brilliant post “Starbucks Does Not Use Two-Phase Commit.” When I read it, my time working at Starbucks during my college years suddenly became relevant. Over the years, I gradually realized there’s even more that programmers can learn from the popular coffee chain.

Although many people may want to build scalable software, it can be much harder than it first appears. As we work on individual tasks, we can fall into a trap, believing all things are equally important, need the same resources, and happen synchronously in a predefined order.

It turns out they don’t—at least not in scalable systems, and certainly not at Starbucks.

Empires fall: Decentralize your code to avoid total collapse

Status fields on entities – HARMFUL?