Microservices Payload Design

There are a lot of people talking about microservices at present. I understand it is fashionable and a lot of people are trying to get rich from consulting in the domain, but a lot of the things I hear are just plain wrong or bad practice.

People are just throwing microservices out there with little consideration of any of the basic requirements of operations. No idea of how they will monitor them; no concept of of how they can debug them and no regard as to how they upgrade them.

I came from a dev background and over time migrated into operations. I dislike fragile, hard to debug components.

I have learnt the hard way just how difficult a distributed microservice architecture can be - but it is still (when designed correctly) a better choice than a hulking monolith of code.

I like my payloads to be debuggable. For this reason I like JSON as a interchange format. It isn’t the most efficient representation format but can be easily human-parsed and is supported by most languages.

I like to know how long a request has taken through the system so I put a uuid and microsecond timestamp when every request is first seen. I also like to know how long each step takes so I also append a timestamp and additional id for every process the request passes through.

Doing these in a uniform way allows you to take a payload from anywhere in the system and be able to use the same tools to perform basic analysis.

It can bloat the payload a little, but being able to see at a glance how quickly each worker is dealing with requests, how long each request takes end to end and what bottlenecks you are seeing allows you to define and keep contracts with your service consumers and detect potential failures before they happen and automatically trip circuit breakers to mitigate some of these issues.

I don’t have all the answers, but this is starting to work well for me.