“Is it still valid to assume it is more expensive to design a scalable system?”

In Gavin Terrill’s news post on InfoQ, Big Architecture Up Front - A Case of Premature Scalaculation? he covers one of the questions so many of my clients deal with:

“How hard will it be to make it scale later?”

This is a valid question, especially for companies/products just beginning their lifecycle. When the product/web site isn’t bringing in any revenue yet, how much money should we spend on getting it ready for that future success?

The answer to that question lies in treating capacity and scalability differently (source).

What I mean by that is designing for scalability, yet separating out all technological aspects of the scaling from the core solution. That way, you can start with simple, low capacity technologies that won’t be too expensive. As you grow, upgrade that infrastructure and plug it in to your solution. Arnon’s  post on Tier Splitting touches on a project we worked on together where we designed it in a way that we could scale down to a single process on a single machine and scale out to a server farm, all without changing the core system.

Let me take the design of nServiceBus as an example:

One primary property of scalable systems is the explicit treatment of all IO/communication. This can be seen in the one-way messaging exposed by the Bus object. There is no immediately evident way to do synchronous RPC-style request/response. This design decision is taken up front. However, the way that messages are passed around is abstracted behind an ITransport interface. You can deploy the first version of your system on MSMQ, and as load increases, switch to a more performant solution like RV or MQ, just by changing configuration. WCF does this kind of abstraction as well.

Another important element of the scalability of a system is how workflow instances are persisted. This behaviour is also abstracted behind an interface - IWorkflowPersister. Start out persisting workflows to a database. As you grow, swap that out of a replicated in-memory cache. In any case, the interaction between workflow and messaging at the logical level is set up front. All the pieces of the design are there. Up front. Helping you design your core application in a way that won’t limit your scalability in the future.

This is plain Separation-of-Concerns; code that works with your specific ESB kept out of your business logic.

Design first, scale with technology later.