Common and Important Terminologies in System Design
Hey everyone!
In this blog, we’ll explore some key terms that are both common and crucial to grasp before delving into system design. This post is part of the System Design for Beginners Series.
If you’re completely new to this, my suggestion is not to overwhelm yourself with too much information. Understand what you can and move ahead ( let the future you suffer 😉 )
System Design
System design, as the name suggests, is designing some kind of system 😗.
Systems of big companies are very complex and wide and so to develop such systems, we need to first plan and find answer to questions like
- How will the system communicate?
- How will the system handle data storage?
- What measures can we take to prevent system crashes?
And the list goes on!
So System Design is basically defining the architecture, modules, and components and how the data will flow through them.
Don’t worry if you don’t understand it fully; this is just to show you what system architecture looks like. 😜
Now you must have heard about high-level design ( HLD ) and low-level design ( LLD )
High Level Design ( HLD ) describes architecture, components, and relations between them. Basically, it concerns services, databases, security, etc.
Low Level Design ( LLD ) describes business logic like classes, objects, interfaces, etc. Basically, how should we code or implement the HLD
Client-Server Architecture
Client-Server architecture is very common terminology that keeps juggling here and there.
In simple words, it simply means frontend-backend (not really, but for now, this is good enough terminology).
Client can be a device that allows the user to access some service or data over the internet. e.g. smartphones, desktops, browsers,etc
Server is a computer somewhere on the internet that runs your code.
Imagine this: you receive a notification that your crush has messaged you on WhatsApp 😉.
When you open the app, your smartphone will request the WhatsApp server to fetch all the messages exchanged between you and your crush
Latency
Latency is the time required to send requests and receive responses successfully.
Latency = Time required to send request + Computational time + Time required to send response
Imagine this: you’re all hyped up after getting a message notification from your crush on WhatsApp 😉. You quickly open the app, expecting to see the message.
But, oh boy, it takes a painful 5 seconds for the conversation to load (frustrating 😡).
That’s why the system aims for low latency, making sure that the chat between you and your crush is fast😜.
Throughput
Throughput is the amount of data transmitted successfully in a certain amount of time.
So when the server sends the response to the client, the data is divided into packets.
Let's say server wants to send 1MB file to client It cannot send it directly. It will divide it into small packets and send them one by one. Like it will send 10 packets of 100 KB
So now assume that for sending 1 packet, it takes 1 sec so it will take 10 sec to send a 1MB file completely.
Hence, the system tries to achieve high throughput.
It is measured in bits per second ( bps ), megabits per second ( Mbps) and gigabits per second ( Gbps ).
Availability
Availability, as the name suggests, is how available your system is
Imagine this: your result for this semester has been released, and the university website, which nobody visits, suddenly gets a lot of visitors.
The university was not prepared for this, and the server crashed. Now, if any client requests data from the server for that client, the server is unavailable.
So to make sure that server is always available, you can create replicas of it so if one server goes down, the client can contact another replica server.
You must have heard recently that Meta server’s crashed in India which led to loss of $ 600 million for only a 2-hour crash.
So, having high availability is crucial in system design.
Consistency
In system design, consistency is all about ensuring that when multiple clients are accessing the same data simultaneously, they all get the same, consistent information.
Let’s understand this by example
Two clients want to book a movie seat for watching Godzilla X Kong . They both request server to get available seat data. Only 1 seat is available.
If client A books the seat before client B, and as the server is storing this information in the database, client B also books the seat.
Assuming system is not consistent, it will allow Client B to book the seat and now we have 2 owners for 1 seat. ( It will be Godzilla Vs Kong for that seat now 🤜🤛)
Hence, consistency is super important if you are creating systems related to banking, ticket booking, etc.
You can further classify consistency into
- Strong Consistency : Don’t allow people to read data until all servers are updated. For Banking, Ticket Booking
- Eventual Consistency : Allow read data, the data will be eventually updated. For Social Media
- Weak Consistency : Allow read data, it might be updated. It depends on business logic
That’s all for today, folks. Catch up with this series later for more updates on System Design Basics from your host and dost — Bhavesh
If you found this helpful, feel free to like it and share your thoughts in the comments! ✨
Next up, we’ll dive into how the internet works.
