title: Microservices and the "single point of failure" concept
body: <p>One concept I don't entirely understand is the single point of failure. It seems to me that whenever you have multiple services, say <code>A</code>, <code>B</code> and <code>C</code>, involved in an entire system, then if any of them is down the system as a whole can't do anything that useful (If the system could be useful without <code>B</code>, then why is <code>B</code> even needed in the first place?).</p>
  
  <p>For example, let's say we have a pipeline such that <code>A</code> publishes an event that is consumed by <code>B</code> and then <code>B</code> publishes a message that is consumed by <code>C</code> and this flow of data is how the whole system serves its purpose. </p>
  
  <pre><code>A ===&gt; B ===&gt; C
  </code></pre>
  
  <p>Maybe <code>C</code> is the service that processes credit card information: the business isn't really running if no money is coming in!</p>
  
  <p>Since this is a messaging system, these services are "independent" in the sense that if one goes down it does not cause another to go down. Ok, but if <code>B</code> goes down then <code>C</code> won't receive any new messages and the entire system isn't serving it's purpose. So, what difference does it make having separate services <code>A</code>, <code>B</code> and <code>C</code> rather than one service <code>ABC</code>?</p>