The Rule of 4

1 min Read Time

At Gilt, we’ve stumbled into something we internally call the Rule of 4:

Q: How many servers should we have for this new app?
A: 4

Q: How many partitions should we split our inventory into?
A: 4

Q: How many nodes should the cart KV store run on?
A: 4

Why 4?

One is not a good idea - building for 1 makes it hard to expand later (e.g. imagine building a service that runs on a single node… it usually takes a lot of work later to modify the service to run on 2 nodes).

Two is better, but still leads to assumptions designed into the code as opposed to configuration.

Three generally works well. By the time an application is built to run on 3 nodes, the node information usually has moved to configuration and services that run on 3 nodes tend to be easy to expand.

So why 4? Our early systems were provisioned in groups of 4 based on load estimates… and worked great. We found that 4 servers was enough for many of the applications / servers we create at Gilt (not every application gets hammered at noon). With four servers, we can safely ramp up traffic for new applications, get real world metrics on performance based on a percentage of site traffic, and then decide how many actual servers we will need to support the full traffic of the site.

HBC Tech

We power the website and mobile experiences for Saks, Saks Off Fifth, Gilt, Lord & Taylor and The Bay.