Welcome to another Sunday article where we dive into system design.

As I already stated: we are going to learn the rules, follow the rules, and once you are an expert — bend the rules.
Let’s keep track of what we’ve learned so far, to keep things at our fingertips even if you haven’t read the previous article.

• A good system design speaks (how components interact)
• Avoid functional decomposition (what we were doing in universities)
• The client should not be the core business. Let the client be the client — not the system
• Reduce coupling between services as much as possible

I’ll be adding more to this list as we proceed in the series.
Remember: we have to learn these rules.

The Anti Design approach

It is very difficult to convince engineers to avoid functional decomposition, since it is the easiest and most straightforward approach. But by the end of this series, I assure you — the readers will be convinced, just as Juval convinced me through his book.

In software companies, when tasks cross deadlines and budgets, there’s often a heavy dependency on tribal knowledge. The design doesn’t speak. New developers become noise and distractions for senior developers in the absence of proper design knowledge transfer. Yet, architects still claim that they’ve been using functional decomposition and it works.

Anti-design is as simple as it is incorrect: just list the functionalities and requirements, and create a service for each(a reminder — by service, I don’t necessarily mean a microservice).

I will try to relate things with examples:

Consider a matchmaking dating application. Just list down all the features and separate them into services. Let different teams code each of them — and boom, the software is ready.
But I will prove that this is a bad design.

The Method says to first perform an anti-design using functional decomposition for the system and keep it for reference — to ensure that at no point are you drifting close to that anti-design. Extending functional decomposition into an actual design is deadly.

The motivation for functional or domain decomposition is that the business or the customer wants its feature as soon as possible. Imagine working on this dating matching software as a team reporting to a manager or client. In a way to show the client that work is going on and to satisfy them, via this functional decomposition, you will make a chat service and show that chat demo. The client is impressed, and then later you build the Matching or Swiping feature. Once the client is again impressed, you start to create user login and profile, and now it’s time to integrate stuff. You tweak the chat service to make sure only correct matches can chat among themselves. You rebuild the chat service on top of the match service. You again rebuild the matching/swiping service to integrate it with the Authentication and Authorization service. This way you keep rebuilding stuff, and within years, the project goes into paralysis by analysis. No one wants to tweak any feature in any of the services as no one knows what else it will break.

This is nothing specific to software. Let’s say an automobile mechanical engineer is designing a physical car. (I am attaching above image to help anyone not clear with the car components terminologies). If he decomposes components according to functional decomposition — braking, acceleration, and turning — imagine him building the braking system on the tires, and then building the acceleration system by attaching the engine, shaft, and gear to the already built wheels, on top of which the braking system has to be rebuilt. The whole chassis has to be redesigned while integrating the steering on the shafts attached to the already built wheels and brakes. It’s rebuilding and rebuilding. Loss of money, material resources, and time.

Imagine adding a double engine, a new hybrid engine. It will push changes in multiple components — the shafts from the turning system as well as the shafts of acceleration system need to be tweaked. One change results in tweaks in so many subsystems. This is a bad design.

Then what is the correct way to decompose?

Decompose based on volatility

Learn this rule — I’ll add it to the master list for the series: Decompose based on volatility.

Volatility-based decomposition identifies areas of potential change and encapsulates those into services or components. The system behavior emerges from interactions between these isolated, encapsulated areas.

The good design based on volatility in case of car includes: the powertrain, the chassis, and the driver/user interface. The powertrain encapsulates the engine, shafts, gears, clutches, shaft system, tires, and the attached braking system. A mechanical engineer designs it as a whole. The chassis is then designed to fit the entire powertrain on top of it, with no rebuilding of another component involved. Finally, the steering, music system, airbags for safety, and cushions are designed and installed in the interior as another volatile component.

Any issue in the engine won't require removing the entire chassis or the airbags. Even an addition like installing an advanced braking system (ABS) is captured within a single volatile component—the powertrain. The design revision to add ABS involves changing just one system. This is volatility-based decomposition.

It’s like placing a bomb inside one component when making a change to the braking system, while being confident that the other components will continue to function safely. The above figure with bomb( a change) and services as vaults is a good representation of a good design.

A brake failure in the chassis component does not affect the other two components. When taken to the mechanic—where the repair documentation is analogous to design documentation in software engineering—the repair will focus on just one component: the chassis. The bill will only cover that one component. This is the elegance provided by mechanical engineers.

A similar principle can be applied to software engineering.

Dating application example

We will look at volatility-based decomposition from 50,000 feet above—rest assured. I promise we will go into detail in the series and learn how to do it using the method.

For now, let’s satisfy ourselves with this: match-making, chatting, and unmatching services should be grouped into one volatile component (say, Component A). Another volatile component (say, Component B) can encapsulate listing profiles, the recommendation system, payment service (for premium), and the user-profile service.

Any extension or change in Component A won’t affect Component B. For example, if a video call feature is added alongside text chat, it won’t affect user data or require changes in the user-profile service. No service in Component B needs to be aware of the changes in Component A. Similarly, any offer added to the premium plan won’t impact the match-making logic. Teams can continue working independently. This is a hallmark of good design.

Updated rule list

Lets add the point we learnt in the rule-list.

• A good system design speaks (how components interacts)
• Avoid functional decomposition
• Client should not be the core business. Let the client be the client and not the system
• Stop coupling between services as much as possible
• Decompose based on volatility

Conclusion

Good design is not about speed of delivery, but sustainability and adaptability. Decomposing based on volatility instead of functionality ensures systems evolve smoothly without breaking apart.

Here are the links to the previous articles in case you missed them:

1. Why Functional Decomposition Leads to Bad System Design
2. System Design Basics: Why The Right Method Matters

In the upcoming articles, published every Sunday, we'll continue our deep dive into system design using The Method.

Stay tuned!