title: Micro-services architecture loose coupling complications
body: <p>I'm fairly new to the whole micro-services bandwagon. I have been doing some research into the architecture and principles behind a good micro-services environment.</p>
  
  <p>One of the main things that defines a micro-service is supposed to be the loosely coupled nature of each service. <em>Micro Service A</em> should never call <em>Micro Service B</em> directly, or you're effectively creating a monolithic system that looses the scalability offered by the architecture pattern.</p>
  
  <p><strong>Question / example</strong></p>
  
  <p>If I develop a micro-service that returns a GUID (for example), it's reasonable to suggest that other micro-services in the environment might call the GUID service directly when one is required. </p>
  
  <p>I understand that a variety of queuing systems can be used to pass data from one service to the next, but in my mind they're for inserting, deleting or updating primarily. </p>
  
  <p>I can't get my head round how a queue would be used for a simple read (like my GUID example) and why you wouldn't just call the GUID service directly from another micro-service. </p>
  
  <p><em>Note: Returning a GUID is just an example, I'm aware most languages are able to generate them internally</em></p>
  
  <p>Some clarity on this would be much appreciated.</p>