One Truth About Technology Architecture: Loose Coupling

One of the great things about being focused on investing in web services is that the technical challenges faced by almost all of the companies in the Union Square Ventures portfolio tend to be the same.  The solutions on the other hand vary widely.  Some companies rack their own servers, others are at traditional hosting companies and some are entirely in the cloud.  Some use Java, others PHP, many mix languages.  You get the idea.  And: there is no obvious correlation between the tools companies are using and how well they are doing.

One pattern, however, has emerged that I now consider as close to a “truth” about technology architecture as it gets:

Loose coupling is necessary to combine scaling and the ability to innovate.

Before explaining what I mean by loose coupling, here is what happens when you don’t do it.  You can either add features rapidly, but not scale – or you can scale, but add features only very slowly.

So what is loose coupling?  It is having different parts of the system work independently of each other and connecting them in a way that if one part changes (or is momentarily slow or unavailable) it doesn’t slow down or kill the entire system.  We do this naturally on the web many times.  As an extreme but common example of loose coupling, blog.somesite.com generally tends to go to an entirely different set of machines running different code, yet with a visually harmonized user experience.  If the blog goes down, the site is completely unaffected (more often it is of course the other way round, i.e. you can read on the blog why the site is down). The same approach can and should be extended deeply into a site or service.  There are many different ways to do this and the point of this post is not to discuss the relative merits of those, but to emphasize the critical importance of loose coupling.

So how does loose coupling enable scaling and innovation?  Scaling bottlenecks tend to move around as a site or service grows.  With loose coupling it is often possible to isolate a bottleneck and prevent it from slowing down everything else.  The part that’s causing the bottleneck can then be fixed (which might involve a complete re-implementation) without much or any need to coordinate with others.  This also points to how loose coupling enables innovation.  Different teams can more easily be in charge of their own part and make changes to it more quickly.  Entirely new parts can be added more easily too (a great example here is Facebook adding chat).

I believe loose coupling is so critical that it should be a board level issue for web companies.  Whenever I now hear something like, “we can’t implement x until we have rewritten y” or “x is slow because y is overloaded” I start to dig in, because it suggests tight coupling is the culprit.