Microservice architecture. Like many topics, you only discover how much you don't know about it until you've crossed a certain line.

Lately I discovered I don't really know microservices because I didn't really know message brokering.

My exposure to messaging technology so far has been merely about tolerating the existence of RabbitMQ. It sits alongside my primary playground (Django), it does enough to deliver, and I didn't bother to get to know what's beyond that because the need didn't come up.

However a series of thoughts led me to believe mastering messaging between distinctive tech-stacks is necessary to keep an architecture from age-decay.

A monolithic architecture, for all its simplicity and upsides has to make do with a pain that only successful ventures suffer: stack upgrades. Upgrades are painful, the return of investment is highly questionable. There two ways of avoiding them: minimize third party packages or simply stop upgrading.

One and a half of these two ideas are good. However, you can only take it so far before your tech stack starts looking like someone with a 1970s haircut. It's still very much alive and mission-critical, but it's not sensible for anything new to be built on top of it.

The way forward for a new module/service is for it to be built using the best tool that makes sense, independent of what's being used by legacy. Yet it still needs to be able work side by side with legacy systems.

And that happens through the simple of idea messaging-passing, facilitated by the likes of RabbitMQ.

What that means is each module/service requires a mechanism to handle messages. Doing so requires protocols; protocols require design.

It's this whole business I'm woefully under-educated about. In the short term I'm pointing my interest in this direction. These are few topics I want answered by the end of it.

Message design

Similar to API design (which this actually is), there must be best practices around designing optimal messaging data structures.

I suspect a lot of object-oriented programming concepts would spill over here.

Asynchronicity

You send a message as a command to do something and need an answer. The answer comes back in an unknown time, to be handled as well as a separate piece of code. Callback-hell ensues.

JavaScript has dealt with enough callback hell to have solved this problem by now. Async in Python might be the answer to this, but similarly I have yet to have the need to play with it to know.

Integration testing

I'm big on automated tests. When it comes back to backend business this is not optional.

I want to find how integration-tests here looks like.

The mistake I've made recently was coding a such a test within one specific module/service when the test needs to be in control of multiple services.

Now that I've looked at it differently, I suspect the proper test suite should sit outside the services. Perhaps the test suite should be a meta-service by itself.