title: What to do when you've really screwed up the design of a distributed system?
body: <blockquote>
    <p><strong>Related question:</strong> <a href="https://stackoverflow.com/questions/2356805/what-is-the-most-efficient-way-to-break-up-a-centralised-database">What is the most efficient way to break up a centralised database?</a></p>
  </blockquote>
  
  <p>I'm going to try and make this question fairly general so it will benefit others.</p>
  
  <p>About 3 years ago, I implemented an integrated CRM and website. Because I wanted to impress the customer, I implemented the cheapest architecture I could think of, which was to host the central database and website on the web server. I created a desktop application which communicates with the web server via a web service (this application runs from their main office).</p>
  
  <p>In hindsight this was rather foolish, as now that the company has grown, their internet connection becomes slower and slower each month. Now, because of the speed issues, the desktop software <em>times out</em> on a regular basis, the customer is left with 3 options:</p>
  
  <ol>
  <li>Purchase a faster internet connection.</li>
  <li>Move the database (and website) to an in-house server.</li>
  <li>Re-design the architecture so that the CRM and web databases are separate.</li>
  </ol>
  
  <p>The first option is the "easiest", but certainly not the cheapest long term. Second option; if we move the website to in-house hosting, the client has to combat issues like overloaded/poor/offline internet connection, loss of power, etc. And the final option; the client is loathed to pay a whole whack of cash for me to re-design and re-code the architecture, and I can't afford to do this for free (I need to eat).</p>
  
  <p>Is there any way to recover from when you've screwed up the design of a distributed system so bad, that none of the options work? Or is it a case of cutting your losses and just learning from the mistake? I feel terrible that there's no quick fix for this problem.</p>