The Three Pillars of Scalability

The three pillars of scalability are statelessness, idempotency, and coding to interfaces.

If you keep the above three in mind, your application can scale a long way with your users. Of course, I am not implying these are the only three things to keep in mind while designing scalable applications.

low-angle-photograph-of-the-parthenon-during-daytime-164336 (1)


If an application does not store persistent state locally, one can scale it by adding servers.

Let us take the example of an application that requires users to sign in. Once a user signs in, the application has to remember that this particular user has logged in. You have the option of storing the logged-in state of the users in the application servers’ memory. When a subsequent request comes, the application looks up in its memory and acts accordingly.

If you are following the above scheme, you are storing the persistent state locally—in servers’ memory. The upside of this approach is its simplicity. The downside is that you cannot elastically scale the application by dynamically adding and removing application servers based on the load.

To figure out whether your application is stateless or not, ask the question: If the next request landed on a different instance of the server, will my operation fail? If the answer is yes, the application is not stateless.


An operation is said to be idempotent if it produces the same result when executed multiple times.


a, b = 1, 2

a + b is idempotent—irrespective of how many times you execute this, the result is always 3.

a++ is not—each time you execute this, you get a different result.

If your application is idempotent, you can retry failed requests. 

Applications can fail momentarily, especially under load. When this happens, ideally, you should retry the failed request. But you can do this only if the application is idempotent. With idempotency, you do not have the unintended side effect of retrying a request.

You are trying to create a user. You hit the user creation API. For some reason, you do not get a response; this could be due to anything—a temporary network glitch, an application error, or something else. The bottom line is that you are not sure whether the user is created or not. If the application is not idempotent, you cannot retry the request. One might end up creating multiple users with the same identity. Not so, if the application is idempotent. One can retry with abandon.

Coding to interfaces:

Coding to interfaces lets us swap components.

You are using a cache in your application. Instead of using the cache provider’s API directly, you hide it behind an interface of your own. In the future, when you have a deluge of users, if you find the cache lacking, you can swap it with a performant cache without incurring tons of maintainability. You can do this only if you decouple your application from the specific cache provider’s API and abstract it out.


It is tough to foresee scalability problems. Following the above generic principles will help you to develop adaptable applications that you can cheaply scale while buying time to create sophisticated scaling strategies specific to your needs.

Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog


How do I Know I am Right?

TLDR; there is no way.

One thing the Coronavirus crisis has made vivid is that no one knows anything for sure. The fact that no one knows anything bubbles up every time there is a crisis. This time though, due to the severity of the mess, it is stark; in your face.

Experts used to say that eating fat is unhealthy. Now, not so much. Not long back, scientists used to believe that the adult human brain is static—once we enter adulthood, our intelligence stops improving. Today, everyone talks about brain plasticity—how the brain keeps growing with the right input even in adulthood and adapts well into old age. The scientific community is staring at a replication crisis—researchers are not able to consistently reproduce experimental results. Marshmallow experiment—one of the most cited psychology experiments, is under doubt.


When I started putting my thoughts in public, I was hesitant. I always had a voice in the back of my mind asking: How do you know you are right? I face the same when someone comes to me for advice. I am guarded with my advice.

How do I reconcile with this?

I have benefitted immensely from the thoughts of others. I am thankful to all these people who take the pain to put their ideas in front of everyone, especially in the current environment where trolling is given. Today, it is fashionable to call anyone and everyone a virtue signaller. Thankfully, I have not gone through the trolling experience as I have a tiny audience.

What is wisdom?

Wisdom is knowledge synthesized with life experiences. By studying, observing, and paying attention, one gains knowledge. One accumulates life experiences by doing. When you mesh the two together and contemplate, you gain wisdom. If no one broadcasted their thoughts, the world would be a sad place.

Strong opinions, Weakly held

An excellent framework for better thinking is: Strong opinions, weakly held. The idea is not to be married to your views. In the face of disconfirming evidence, update your beliefs. Interestingly, even this maxim is under debate.

There is no way for you to be a hundred percent sure of anything; this applies when you give and receive advice. The best you can do is color your knowledge with your life experiences and share it with others in the hope that the other person takes something positive out of it—a small way for you to give back to the society.

Always be skeptical.

Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog


Should I or Should I Not

This post walks you through a framework for adopting new technologies. Microservices is a placeholder in this post. It is a generic framework that you can apply to any new technology that you are planning to adopt.

Should we do microservices?

The above question plagues the minds of software developers.

Popular programming culture made microservices the de facto way to build software. Now, many are second-guessing their choice.

Here is a post from Segment on why they consolidated their microservices into a monolith.

Microservices is archetypical of software trends following the Hype cycle. In the Hype cycle, microservices has passed the “Peak of Inflated Expectations.”

Hype Cycle

A framework for making new technology choices

Before adopting any new technology, you have to:

  1. Clearly define the problem you are trying to solve with the novel technology.
  2. Understand how the new technology solves the problem.
  3. Build perspective by studying the evolution of the technology.
  4. List the supporting structures needed to make the new technology work.

[ Click to Tweet (can edit before sending): ]

The above may sound meh, but taking the pain to define them to the T is the key to the success of new technology adoption.


Clearly define the problem you are trying to solve

Nailing down the problem is the first step. You would be surprised by the number of people who try to solve a problem without defining it formally.

When the problem that you are trying to solve is vague, it becomes tough to find a solution to it. How many times has it happened to you that you describe a problem to someone, and in the process of doing so, you get closer to the solution?

Clearly define the problem that you are trying to solve with microservices. Is it a performance problem with the application? Are you trying to increase the productivity of the team with microservices?

When you do this, sometimes you find non-disruptive ways to solve the problem. Better communication between teams might be the solution, not microservices.

Understand how the new technology solves the problem

Understanding how the new technology solves the problem will help you to evaluate it objectively. Defining the problem, as stated in the first step of the framework, is essential for this.

There are two broad reasons for microservices adoption—technical and logistical.


The application has grown in complexity and has workloads vying for different types of resources. You are not doing justice to any of these workloads by packing them in a monolith. For example, some workloads might be CPU intensive, some IO heavy, and the others hungry for memory. By extracting each of these workloads into a microservice, you have the freedom to host them in different servers conducive to their demands.

The application has grown in complexity and has workloads better solved in different programming languages. Breaking the monolith into microservices gives you the ability to code them in the programming language of your choice.


The application has evolved as well as your company. Different teams are responsible for different areas of the application. You want these teams to be independent. If you break the monolith into microservices that mimic the team structure, you will achieve this independence. These teams can work independently without stepping on each other’s toes, thus being more productive.

Build perspective by studying the evolution of the technology

When you try to dig up the history, keep in mind that you are not going after the rigorous academic definition of the term, but the cultural context of its evolution. The common definition of a term may not match with its formal description. For example, when people say microservices, they are usually referring to Services Oriented Architecture(SOA) and not microservices in particular.

Microservices exploded due to big companies like Amazon and Netflix evangelizing(maybe unintentionally) them. These companies have thousands of employees and divisions. Once you understand this and build a perspective, you will naturally ask, is this applicable to me? If you are a small startup that can count your tech team with one hand, in all probability, the answer is no. It is tough to build this perspective without studying the evolution of the technology.

Supporting structures needed to make the new technology work

Whenever you introduce a new technology, you might have to make some changes to the way you work. Some of these changes might be inconsequential, and others extensive.

For microservices to be successful, you will have to invest in tooling. You will have to have a robust monitoring system because, with microservices, you are treading into distributed computing where failure is a given. I will stop here as this requires a post in itself.

In many circumstances, these changes might be far-reaching negating the benefits of the new technology. Be keenly aware of this trade-off.


Doing this might sound time-consuming, but it pays off by preventing unmitigated disasters down the line, once you are in the middle of adopting the new technology. Many new technology choices bomb because someone did not do the above painstakingly enough.

Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog

Hype Cycle image By Jeremykemp at English Wikipedia, CC BY-SA 3.0,

Photo by Miguel Á. Padriñán from Pexels

Let go of Stereotypes

The key to building a great team lies in ejecting the stereotypical portrayal of the role from your mind, objectively figuring out the qualities needed for success in the role, and ruthlessly going after that.


What is the stereotype of a leader?

A charismatic extrovert who can spellbind an audience with her talk.

Leadership is not about how charismatic you are or how good you are at public speaking. Popular culture has narrowly defined leadership to be so.

In the book, The Little Book of Talent, the author Daniel Coyle writes: Most great teachers/coaches/mentors do not give long-winded speeches. They do not give sermons or long lectures. Instead, they give short, unmistakably clear directions; they guide you to a target.

What is the stereotype of a developer?

This twitter thread does an excellent job of it.

Being a good developer is not about which editor you use or how socially awkward you are. These are urban legends devoid of any real substance.

Leaders and developers come in all shapes and sizes. Take a step back and think of all the great people you have worked with. Do they stick to the stereotypes associated with their role? Can you pigeonhole them into a mold?

The movie, Money Ball, is the best illustration of this line of thinking. The plot of the film revolves around the real-life story of a manager who assembles a successful baseball team analytically by ignoring the mythical stereotypes associated with what makes one a successful baseball player. This approach of building the team was not a cakewalk for him; he met with resistance from all for his radically different line of thinking.

Peter Thiel talks of startup hiring as finding the talent which the market has mispriced(I am paraphrasing this from memory).

If you stick to stereotypes while hiring and promoting, you are:

  1. Artificially restricting the available talent pool.
  2. Pursuing the same set of people that everyone else is.
  3. Going after qualities that you do not need.

We are sympathetic to underdogs, but we do not bet on them. Doing so is the not so secret strategy for building a great team.

Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog