System Design Unleashed series #1: On the usage of Abstractions
The abstraction is the process of focusing on the important characteristics of the system while omitting irrelevant or non-important implementation details. It allows us to focus on complex components by looking at them through a simplified lens. Abstractions can also be defined as the separation of the how and the what, that is, avoiding discussing how a component is doing a specific task, and focusing on what the component is doing in general.
Now, the important point to mention right away is that we are not discussing the Objective-Oriented Programming concept of abstraction and abstract classes (depending on the programming language, the implementation and usage of abstract classes can slightly differ, but in a nutshell, an abstract class is a class with at least one method which is not implemented). Here, we are strictly discussing abstractions in a System Design context.
The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. — Edsger Dijkstra
What Dijkstra states in this sentence is that, when we are discussing abstractions, we should find the right level of abstractions: Don’t go too low level, but don’t zoom out a lot either.
Let us focus on the car picture above to understand what Dijkstra meant. Although the sketch is beautiful if we wanted to abstract the concept of a “car”, this would be absolute overkill due to the number of small details, moreover, it might cause confusion as you may think that the author of the picture wanted you to focus on a specific class of cars, old-timers, not the cars in general. If we wanted to showcase the abstraction of a car - a simple car icon would do the trick.
So, how do we apply the power of abstractions in Software Architecture and System Design? Let us take a look at one of the most common architectures created in the web era, the three-tiered architecture.
The abstraction of a Presentation tier essentially means: “Users have a place to see the content of the service they want to interact with”. The deeper explanation would sound like this: “The users can access a website where the content is served in HTML and stylized through CSS. Users can also access the website through their phone or a tablet, and the website will automatically resize to fit their screen. In addition, iOS/Android users can download the app from the respective app stores and view the content through the app to have the native experience”. If we wanted to, we could find a way to represent the deeper explanation on an image — but if we are interested in designing the system from a high-level perspective, it is not needed, what is needed to showcase is that users have an entry point and that is it, period.
Similarly, if we zoom in on the Data tier we can easily overengineer and waste time discussing the database implementation. In system design, the most common practice is to stop at the level of a database type (e.g. do we need a relational or non-relational database, and in case we are choosing a non-relational database, which subtype to choose).
Abstractions are common in the Industry
Almost every SaaS (Software as a Service) company uses abstractions on their websites to showcase how their service can be plugged into broader customers’ ecosystems. E.g. if we take a look at the description of AWS Lambda, it states:
AWS Lambda, a serverless compute service, executes your code in response to events, handling compute resources for you.
Of course, the description and the diagram of one concrete use case don’t teach you how to use the service, but the abstraction above gives you enough information to understand whether AWS Lambda is something you are interested in or not.
Using the right level of abstraction makes it easier to reason about software components without trying to understand their internal workings. By focusing on a high-level overview of a system, we can zero in on the most important and relevant characteristics at that point in time, and don’t waste time on things that aren’t relevant or can be discussed during the implementation phase. Abstractions are an important concept and they will be used throughout the System design series.
