Building Microservices with Go

Naming conventions

Defining a naming convention is incredibly important since, once you start to collect data, a point will come where you need to analyze it. The key thing for me is not to define a convention for your service, but a convention that is useful for your entire estate. When you start to investigate issues with your service, more often than not, you will find that the problem is not necessarily with your service, but could be due to a multitude of things:

• Exhausted CPU on host server
• Exhausted memory
• Network latency
• Slow data store queries
• Latency with downstream services caused by any of the preceding factors

I recommend you break up the name of your service using dot notation such as the following:

environment.host.service.group.segment.outcome ...