DEV Community: Blackwatch

System Design 101 - The Building Blocks Every Developer Should Know

Blackwatch — Sat, 31 Oct 2026 13:51:13 +0000

As a software developer why do we need a system design, isn't this one extra, "UNNECESSARY" step?? If we can directly jump into coding, make applications and make changes on the go. Well... right and wrong too.

For very simple applications like a todo list or a color changer, no system design is required. But when we talk about masses, lot of data moving from one point to another, lot of users accessing the services at the same time, sudden surge in the usage etc. there we need system design.

Think of it like this, when you are making noodles for yourself, you don't think a lot. But when you have to cook for 20 people, you prepare a whole plan first and only then execute it. That is system design. Designing the whole plan of how things will work and how things will take place, before actually picking up the tools (here, coding). It gives a clear cut idea of what we are building, and in case we are stuck, we can always refer back to it.

In one line, System Design = Components + a Common Goal. Lots of small pieces (database, server, cache, load balancer...) all working together to achieve one goal.

In this article I will walk you through the 7 core components of a system and the main ideas around them, so treat it as your System Design 101.

Requirement - Little bit of technical knowledge before hand (what a server, database and API roughly are).

What Are We Even Dealing With? Data!

At the end of the day, almost every application is moving data around. Mainly it is one of these:

Video
Audio
Text
Images

Keep this in mind, cause every component we discuss below exists to store, move, or serve this data better.

The Components

Here is the list of components we will look at:

Database
Server (Application Layer)
Frontend (Client Application Layer)
Cache Layer
Load Balancer
Message Queue
Monitoring and Logs

Let's start with the first one.

1. Database

The whole point of an application is to manage, deliver, present and analyse data, and give it to the users in a usable manner. A highly sophisticated application without data is of no use. So to hold this data for future operations, we need a place to store it, and that place is called a database (DB).

Now we have two types of databases.

SQL (Relational Databases)

SQL stands for Structured Query Language. Technically SQL is the language we use to talk to the database, and the databases that use it are called Relational Databases (MySQL, PostgreSQL, Oracle etc.), but in day to day talk everyone just calls them "SQL databases".

It's all about storing data in a structured manner. It uses tables (rows and columns) and close relations between these tables to present data. Every entity gets its own table, like Users, Posts, Pictures, Comments, Blogs.

Here is a small users table, every row is one user:

id	fname	lname	phone_no
1	Example	Test	9874597890

These are good for complex queries and transactions. A transaction is a group of operations which either all happen or none of them happen. Imagine sending money to a friend, money should go out of your account AND come into theirs. If only one of these happens, that's a disaster. SQL DBs guarantee this using ACID properties:

A - Atomicity - all or nothing
C - Consistency - data always follows the rules we set
I - Isolation - two transactions running together don't mess up each other
D - Durability - once saved, it stays saved, even if the power goes off

No-SQL (Non-Relational Databases)

Good for unstructured data and ingesting data in bulk. Stores data as key-value pairs, documents, columns or graphs (we'll see each type below). No fixed structure, in the first object we can save only one value while in the second we can store 50 values, no issue. Meanwhile SQL is structured, every row follows the same structure.

Here we will focus more on SQL first.

Constraints

While creating a table in SQL, we can set some rules which need to be followed to ensure consistent and good data. These rules are called constraints. The common ones are:

NOT NULL - value can't be empty/null
UNIQUE - every value in that column has to be unique (like email)
DEFAULT - sets a default value if nothing is passed
CHECK - value must pass a condition, e.g. age >= 18
PRIMARY KEY - the unique identity of every row, like the id column. It is UNIQUE + NOT NULL together, and a table can have only one primary key.
FOREIGN KEY - a column which points to the primary key of another table. This is how tables get connected. E.g. a posts table has a user_id column which points to users.id, so every post knows which user it belongs to.

This is important cause users will feed data, and it's our responsibility to ensure that it's correct and following a particular format.

Joins

Used to combine two or more tables (using the related columns, usually the foreign key) and then run a query on it to extract the required data. Most common ones are:

INNER JOIN - only the rows which have a match in both tables
LEFT JOIN - all rows from the left table + matching ones from the right
RIGHT JOIN - all rows from the right table + matching ones from the left
FULL JOIN - everything from both, matched where possible

Example - "Give me all posts along with the name of the user who wrote them" = join posts and users on posts.user_id = users.id.

Relations

This describes how two tables are connected with each other.

One to One - one user has one profile, one profile belongs to one user
One to Many - one user can write many posts
Many to One - many posts belong to one user (same thing as above, just seen from the other side)
Many to Many - a student can enroll in many courses, and a course has many students. For this we use a third table in between (enrollments) which holds student_id and course_id.

DB Scaling (the basics)

We know that each DB has a limit, it can't store unlimited data magically. To ensure it's healthy and running, we need to scale it as the users/data increase. Ways to scale it up:

Vertical Scaling - increase the resources of the same machine - RAM, storage, CPU etc. But it can be done to a particular extent only, you can't keep adding RAM forever.
Horizontal Scaling - add more DBs (more machines).

Issue with horizontal scaling in SQL is that it's tedious/hard. SQL data is connected through relations, so once it's spread over many machines, a single JOIN or transaction may need data from 3 different machines, and that gets slow and complicated. While in No-SQL every document stands on its own, so it can sit on any machine without worrying about the others. (We will dig deeper into DB scaling later in this article.)

No-SQL in short

Easy to scale
Schema less
No heavy linking between different entities, unlike SQL's relations
Every entity stands on its own

When SQL, When No-SQL??

SQL - payments, transactions, places where data is structured and consistency is a must
No-SQL - scale, speed, unstructured data

Consistency  >>  Availability                      =>  SQL
Availability + Scalability  >>  Strict consistency  =>  No-SQL

Types of No-SQL

1. Key-Value DB

The simplest one. Every piece of data is stored as a unique key and its value. The value can be anything - JSON, string, number, blob, array, or a combination of them. Think of it like a giant dictionary, give the key, get the value, super fast.

Used for - cache, cookies/sessions, simple data storage.
Ex - Redis, Amazon DynamoDB.

2. Columnar DB

Similar to a table in SQL, but it stores and reads data column wise. Normal SQL DBs read the table row by row, so in case we want only the marks column, a relational DB will still read row wise. Columnar DBs allow us to read only the columns we need.

ID	name	marks
1	name1	90
2	name2	95

Ask "what's the average of marks?" and a columnar DB reads only the marks column (90, 95), it doesn't even touch the names.

Ex - Google BigQuery, Amazon Redshift, Snowflake, ClickHouse (these actually speak SQL, but they store data column wise, which is the idea here).

Good for analysis, like reading millions of rows to build a report
Writing in this is slower than other No-SQL DBs

3. Graph DB

Data is stored as Nodes (the entities) and Edges (the relationship between them). Both nodes and edges can have properties. Like a Student node connected to a Course node with an "enrolled" edge, and that edge holds the year, marks and year of passing. Good to find hidden patterns in analysis/research, like "friends of friends" on social media or fraud detection.

Ex - Neo4j.

Cons - complex to design, and slow for normal bulk queries which don't need relationships.

4. Document DB

This one is used widely. Data is stored as documents, usually JSON-like objects (each document is like a key-value pair, where the value is a whole object).

Flexible
Schemaless
No relations
Ex - MongoDB

Good for - logging, user profiles. Like an Instagram post, one document can hold the image, video and text together.
Reads are fast cause one document has everything, no joins needed. But if the same data is copied into many documents, updating all of them gets messy.

2. Server (Application Layer)

The backbone of any application. It is responsible for doing the heavy lifting, does all the operations, fulfils users' requests and acts as a connecting bridge between the frontend and the database. It hides the complexities of the DB and gives easy access to it through APIs -> Endpoints (CRUD - Create, Read, Update, Delete).

3. Frontend (Client Application Layer)

The device you are using currently to read this article, the website or the mobile app. The GUI, or the front face of any application through which the user interacts, is called the frontend.

4. Cache Layer

A cache is a small but very fast storage (mostly kept in memory/RAM) which keeps the most asked data, and it mostly sits in between the server and the actual DB.

Imagine a store, you walk into it and see that most of the items are kept on their shelves while some of the most used items are kept right on the counter. The shelves are our DB, while the items on the counter are our cache, for quick and easy access.

Now imagine a situation, your website has a hero section where you are showing 6 courses, and each course needs an image, course details, price and a preview.

Single user  = 6 courses x 4 APIs        =        24 requests
10,000 users = 24 x 10,000               =   2,40,000 requests

So 24 requests just to populate the hero section for a single user. Now imagine 10,000 users land on the site, it becomes 2,40,000 read requests to the DB, all asking for the exact same data. So we cache it and serve it from there only, cause it's not going to change, it's the same for every user. It saves bandwidth, decreases latency (the delay between asking for data and getting it) and improves user experience. And remember, high latency = poor performance = bad UX = business loss.

Important terminology

Cache Hit - data is present in the cache = fast response
Cache Miss - data is not in the cache, so we go to the DB = slower response
TTL (Time To Live) - expiry time of the data in the cache. Once the TTL is over, the data is removed and fetched fresh next time.

Storage in cache

Data in a cache is stored like this:

Key	Value	TTL
course_6_price	499	1 hr

And cache size <<<<<<<<<<<< actual DB. The cache is kept small cause it lives in RAM, which is expensive. So we only keep the hot data, the stuff that's asked for again and again, otherwise it will become just another simple DB.

Caching Strategies

1. Read Through Cache (RTC) - for reading

First we will read the cache, if it's a cache miss then only we will read the DB and update the cache on the way back. (In pure read-through, the cache itself goes to the DB on a miss. When our app code does that job instead, it's called cache-aside, but the idea is the same.)
For write requests, it always goes to the DB first.

2. Write Through Cache (WTC) - for writing

Every write goes to the cache and the DB together, the write is done only when both are updated. So the cache always has the latest data.
Good for fast paced data where the latest data matters - like stock values.
Downside - writes are a bit slower, cause we write at two places.

3. Write Around Cache (WAC)

Writes go directly to the DB, no cache update. Reads always go through the cache, on a hit we return, on a miss we go to the DB, update the cache and then return.
Good when data is written once and rarely read immediately after, so we don't fill the cache with stuff nobody asks for.

4. Write Back Cache (WBC)

In this, the data is first written in the cache and the response is sent back to the BE (backend) right away, the write on the DB happens asynchronously. The issue is that there may be inconsistency, what if an error occurs while writing to the DB, or the cache crashes before saving? That data is lost.
Read is similar to above.

Speed >>> Consistency is the trade-off here.

Ex - high write traffic, like Swiggy/Zomato/Uber Eats where order status and delivery location update very quickly.

Cache Eviction Strategies

Cache is small, remember? So when it's full and new data comes, something has to go out. Who goes out is decided by eviction strategies.

LRU - Least Recently Used - remove the data which hasn't been used for the longest time. The most common one.
MRU - Most Recently Used - remove the data which was used most recently. Sounds weird, but think of streaming services, once you've watched an episode, you are not going to watch it again, the next episode is what you need.
LFU - Least Frequently Used - remove the data which is used the least number of times.
FIFO - First In First Out - remove the oldest added data, like a queue.
LIFO - Last In First Out - remove the newest added data, like a stack of plates.

5. Load Balancer

As the application grows, we can't just rely on a single server, can we? What will happen if that server faults and goes down? The whole application will be unusable. To mitigate this and to give quick responses to the incoming requests, we have a cluster of servers working together. Now how will a request know which server to hit? For that we have the Load Balancer (LB). It decides which request will go to which server and maintains the load on the servers, so no one server dies under heavy load.

Responsibilities of LB

Choosing the server
Checking servers' health

LB Algorithms

1. Round Robin

Selects servers in numerical order, checks nothing. With 4 servers it goes 1, 2, 3, 4, 1, 2, 3, 4...

Easy to implement
Equal distribution

Issue - what if the servers aren't of the same config?

	S1	S2	S3
RAM	4 GB	8 GB	16 GB
Storage	100 GB	200 GB	300 GB
CPU	16	32	64

Here S1 will face difficulties to keep up with the others, cause it isn't capable enough to match them, but it still gets the same number of requests.

2. Geo Based Algo

Based on the server's and user's location. The servers are spread across the globe and the nearest one to the user is selected to entertain its requests. A user sitting in India gets the India server, not the US or EU one.

Less latency
Increases performance

Cons

LB needs to manage extra details - location of servers, user location, and constantly check servers' health
DBs across regions need to be maintained, ensuring the data is uniform everywhere
VPN/Proxies can mislead the traffic. If your VPN says you are in the US while you are sitting in India, you get routed to a US server, that's one of the reasons your internet feels slower on a VPN.

3. Least Connection Algo

The server with the least number of active connections gets the next request.

Disadvantages

What if the server with the least connections is handling a heavy task, the next request is still sent to it. It will choke.
LB needs to keep records of the connections of each server to implement it.
What if some servers have fewer resources, still they will get the request -> slower response.

4. Least Time Algo (Least Response Time)

Selects the server with the least response time, eventually giving less average time. If S1 is answering in 50ms and S2 in 10ms, S2 gets the next request.

Less response time = usually high config server.
Ex - real time apps like trading.

In this the LB needs to calculate the average response time of each server, which depends on the type and config of the server, number of requests etc. It's complex, plus it keeps changing with the traffic.

5. IP Hash Algo

The user's IP is passed through a hash function (a function that turns any input into a number, and the same input always gives the same number), and the result decides the server. So the same IP always lands on the same server, good for keeping the user's session on one server. Good thing, the IP rarely changes in a single session, but the moment the connection breaks or the service provider changes, the IP changes. If the server changes, then the user's data needs to be there on the new server too. E.g. hash values 1-10 go to S1, 11-20 to S2, 21-30 to S3.

Major disadvantage - Scaling. New server -> hash ranges change in the LB -> new mapping for every server, so lots of users suddenly get shifted to a different server. (Consistent hashing is the technique used to reduce this reshuffling.) Not a great fit for microservices where servers come and go often.

6. Weighted Round Robin

In this, each server is assigned a weight/value, and the load balancer uses these weights to distribute the requests in a sequential manner.

Imagine server A with weight 1 and server B with weight 3. The LB will send 1 request to server A and 3 requests to server B, then again 1 to A, and so on. This fixes the issue of normal round robin with different config servers, give the powerful one a bigger weight.

In reality we use hybrid algos, we don't rely solely on a single algo.

Health Check

How does the LB know a server is down? By checking its health.

Passive way - checks the responses of the already sent (actual) requests. If they keep failing, something is wrong.
Active way - by sending extra requests (pings, like hitting a /health endpoint) after a particular interval to check if the server is up and running.

Parameters for Health Check

Interval - how often we check our server's health. Every 5 sec, every 2 hrs etc.
Timeout - how long do we wait to get a response before calling it a failure. E.g. if a server normally responds in 50ms (min) to 5 sec (max), then a response taking 10 sec is alarming.
Threshold - setting the limit for when to change the server's status.
- Unhealthy threshold - after how many failed checks in a row we mark the server unhealthy and stop sending traffic to it. E.g. 3 failed checks in a row and the server is out.
- Healthy threshold - after how many successful checks in a row an unhealthy server is considered healthy again and gets traffic back. E.g. n successful calls -> everything is going good, bring it back.

DB Scaling - Deep Dive

We know vertical scaling is good but it has its limit, after that we need to add more DBs. And we can do that in a better way too, using Replication and Partitioning.

Replication

Keeping copies of the same data on multiple DBs.

Avoids Single Point Of Failure (SPOF) - one DB dies, others are still there
Keeps data closer for faster retrieval
Read throughput increases

Single DB -> 10,000 reads/s
2 DBs     -> 10,000/s x 2
3 DBs     -> 10,000/s x 3

Writes don't scale like this though, every write still has to reach every copy.

Replication Algos

1. Single Leader Replication

One leader, n followers. The leader (L) takes all the writes and passes them on to the followers (F). Reads can be served by any of them.

In this, the write operation can be done in two ways, sync and async.

Sync

The leader waits till every follower confirms the write, then only says "done" to the user.

Advantages

Followers are always updated
If the leader fails, the followers still have up to date data

Disadvantages

Longer response time - need to wait for the response from each follower DB
Blocks resources
Impractical - if one follower is slow or down, every write gets stuck

Async

The leader saves the write, says "done" to the user straight away, and updates the followers in the background.

No blocked resources
Fast response

Disadvantage - mismatched data. A user may get stale data from a follower which isn't updated yet, while another user gets the updated data. (This delay is called replication lag.)

In real life, many systems go in between - one follower is sync and the rest are async (semi-sync), so at least one copy is always up to date.

How to add a new follower

First create a snapshot of the current system, at that moment, with a timestamp.
Use this snapshot to feed data into the new follower, assume it took 3 hours.
In those 3 hours new data came in. So now get only the changes made after the first snapshot (the DB keeps a log of all changes, so we just replay it).
Populate this data.
Connect it with the actual system.
Congrats, new follower added!

How to elect a leader if L fails

Check which follower has the latest data.
Promote F1 as the leader and update F2 to see F1 as its leader.

(Also make sure the old leader, if it comes back, knows it's not the leader anymore, otherwise we get two leaders, called split brain.)

2. Multi Leader Replication

More than one leader, usually one in each data center. Each leader first populates its own followers and the other leaders, which then populate their followers.

Users write to the nearest data center, so writes are faster
Multiple leaders = more fault tolerance
Collaborative editing (like Google Docs)
2 leaders can write on the same data in parallel, but this increases the chances of conflict.

To resolve conflicts:

Last write wins - the latest timestamp wins
Replica/Leader with the higher value assigned wins - each leader gets an ID/priority, higher wins
Do nothing - pass the conflict to the user and the user will pick the value (like git merge conflicts)

3. Leaderless Replication

No leader. Every query (read/write) goes to multiple nodes to get the response. (Ex - Apache Cassandra, ScyllaDB, Riak.)

Say User1 updates some data, DB1 and DB2 get it but DB3 misses it. Now when User2 reads, DB1 and DB2 give the updated data while DB3 gives stale data.

So do users need to wait for the response from every DB??

Nope. There are different algos and we can follow one of them. One of them is Quorum. We wait only for enough DBs to make w + r > n (explained below), not all of them.

Servers  n = 3
Write    w = 2   (wait for 2 out of 3 to say ok)
Read     r = 2   (read from 2 out of 3)

Rule:  w + r > n   ->  2 + 2 > 3

Why does this work? Cause if 2 DBs have the new write and we read from 2 DBs, at least one of them will surely have the latest data.

For a read, say:

Response 1 = updated data
Response 2 = stale data

Every value carries a version number, so we pick the one with the latest version, and also fix the stale DB on the way (read repair).

Partition (Sharding)

Issue with replication:

What if the data itself is huge? Every copy still holds ALL of it.
Time for searching/any other action keeps increasing.

So here we divide the DB into smaller pieces, called partitions (also known as shards), and each partition can then be replicated too.

Only rules:

When the partitioned DBs are connected together, they should give the entire data back.
Data should be equally distributed. (One partition with 90% and the other with 10% is no good.)

Partition Algos

1. Partition by 'key' (range)

Say we have 10,000 users. Users 1 to 5000 go to P1, and users 5001 to 10000 go to P2.

Hotspot - a partition getting much more traffic/requests compared to the others, which may lead to node failure. E.g. if a big chunk of the newly active users fall in one range, that partition gets hammered while the other one chills.

2. Partitioning the data with 'hash' of key

Based on the value of a hash function, the data is spread more randomly and evenly. U1 hashes to 1 so it goes to P1, U2 hashes to 2 so it goes to P2, U3 to P2, U4 to P1 and so on.

Issue still persists, what if a single key becomes a hotspot (think a celebrity account with millions of followers)? Plus range queries like "users 1 to 100" now have to check every partition.

3. Partition by Secondary Index (local index)

We often search by something other than the key, like "all users from India". So each partition maintains its own secondary index for its own data. Writes are fast (just update the local index), but a read has to ask every partition and combine the results.

4. Common Global Index

One global index covering the data of all partitions (and the index itself is partitioned).

Better reading - we know exactly which partition to go to
Slower writing - one write may need to update the index on another partition too

CAP Theorem

C - Consistency - every read gets the latest data
A - Availability - the system always responds to every request
P - Partition Tolerance - the system keeps working even when the network breaks and some nodes can't talk to each other

⚠️ Careful, the "P" here is not about partitioning/sharding our data like above. It's about a network partition, when the connection between nodes breaks.

CAP theorem says that in a distributed system, we can only provide two among the three at a time.

Combinations:

CA - Consistency + Availability, no partition tolerance. Only really possible with a single DB, cause there is no network between nodes to break.
CP - Consistency + Partition tolerance. When the connection breaks, the out of sync node stops serving (or the system waits) until it is restored and updated with the latest data. Users may get an error, but never wrong data.
AP - Availability + Partition tolerance. When the connection breaks, everyone keeps serving, so users may see stale or outdated data for a while.

AP = Instagram - seeing a like count a few seconds late is totally fine
CP = Bank - showing a wrong balance is NOT fine
CA = Small app - single DB, no distribution

In reality, network failures will happen in any distributed system, so P is a must. The actual choice is between C and A when things break.

Sync vs Async Requests

Before message queues, we need to know that there are types in requests too, Sync and Async.

Sync - the client sends a request and waits till the response comes back. Used in finance apps, security checks, and dependencies where one service depends on the result of another.
Async - fire and forget. The client sends the request and moves on, the work happens in the background. Used for broadcasting, emails, SMS/WhatsApp notifications.

Example - E-commerce. Once a product is purchased, updating the inventory is sync (we must know the stock is updated), while sending the email and starting the delivery are async.

6. Message Queue

What happens when you place an order on a food ordering app? It first takes your order, then sets it to preparing, then packaging, picked up, delivered etc. Or when you book a flight, you get a message, email, WhatsApp, saying thank you for choosing xyz airlines, here is your ticket. Ever wondered how this works? If each of these features is handled by the main server, it will put additional load on our servers, while these don't need to happen instantly.

So we have a Message Queue (MQ). Once the ticket is booked, the server pushes the email, message and WhatsApp tasks into the message queue, from where they are picked up by their respective services and the task is done. These aren't as urgent as the booking itself, therefore they can be done asynchronously.

A message queue is like a buffer placed between the app (backend) and a service, and it's async in nature. It's helpful as it allows the app to shed some load onto the queue. So in case a request fails, the queue handles it on its own (retries), otherwise the backend had to handle it, which would be an additional load on it.

The one sending messages is the Producer/Publisher, the queue in between is the Broker, and the one picking them up is the Consumer/Subscriber.

Ex - RabbitMQ, Apache Kafka, Amazon SQS.

Qualities of MQ

Can hold requests
Communicates with services
Handles failed calls
Handles the load of services

MQ Algos

1. FIFO

Strict order - messages are processed exactly in order. If one fails, it will not proceed, it will wait for its completion and then only move forward. Blocking in nature. 1 ✓, 2 ✓, 3 ✗... and the queue waits on 3.
Unordered queue - skips the failed request and moves on to the next one, the failed one is retried later (or goes to the DLQ). 1 ✓, 2 ✓, 3 ✗ (skip), 4 ✓, 5 ✓.

2. Priority Queue

Attach a priority number with the call and higher priority ones get processed first. E.g. OTP SMS before a promotional email.

3. Pull Based

Requests are fed into the queue and the consumer pulls the requests on its own, whenever it's ready.

4. Push Based

Here the MQ pushes the request/call to the consumer as soon as it arrives.

Pub Sub Model

In a normal queue, one message goes to one consumer. In Pub/Sub (Publish/Subscribe), publishers publish a message to a topic, and every subscriber of that topic gets its own copy. Subscribers can get it pushed or pull it themselves.

Ex - an "order placed" event, the email service, the inventory service and the analytics service all subscribe to it and each one does its own job.

DLQ - Dead Letter Queue

Calls which couldn't be processed by the consumer, or had issues even after retries, are moved into a separate queue called the Dead Letter Queue. Later a log is given to the producer/developers for analysis of what went wrong and where. This way the bad message doesn't block the main queue, and it's not lost either.

Use Cases of MQ

Async tasks
Analysis / analytics events
Load balancing / load levelling - absorbing sudden spikes so services work at their own pace
Deferred systems
- do them later
- scheduled processes

When not to use it:

Don't use it for a small app with low traffic, a queue is one more service to pay for, run and maintain.
Real time stuff where the user is waiting for the result right now, big no. If we need an immediate result back from the other service, call it directly.

7. Monitoring and Logs

As developers, our work doesn't stop when the project is deployed or handed over, we need to ensure that it's up and running all the time. For that we need logs to see where the issue is, so that we can recreate it and fix it. Creating the app is just step one, maintaining it is the longer journey.

Fault/Error

Any condition where the system isn't working the way it's supposed to.

Hardware based
- Server, DB, RAM failures
- Overheating
- Power supply
Software issue
- Bad code
- Edge cases
- Config issue
- Deployment issue
- Merge requests/conflicts
- Latency
- Performance
Human fault
- Unpredictable
- Unreliable
- Yet this is our power too, which makes us different, humans learn from experience and improve.

Monitoring and Observability

Monitoring tells us that something is wrong (CPU at 95%, errors increasing). Observability helps us understand why it's wrong, using the three pillars:

Logs - what happened, line by line
Metrics - numbers over time (CPU, latency, error rate)
Traces - the full journey of one request across all the services

Monitoring API

Throughput - how many requests the server is handling per second
Error codes (response codes) - how many 4xx/5xx we are throwing
Health check - passive or active
Latency - how long a response takes

Machine Monitoring

CPU usage - 75% -> alert
Memory - 90% -> scale up
Disk I/O - near limit -> alert
Network I/O

What Type of Application Is It?

Before jumping on to designing the system, we first have to understand what type of application it is. Is it:

Data Intensive
Compute Intensive

Data Intensive Applications

Here more focus is on data, how to gather it, store it, move it, operate on it and how to present it. Imagine Instagram, it is filled with data, be it reels, messages, photos, comments etc. WhatsApp messages, banking transactions, analytical dashboards etc.

From the point of technology, the main things we need to look at are the response from the database, network calls and server upgradation.

Primary goal - serve data from the DB to the user faster. Not much computation is required.

Worries

How fast can we read the data
How safely are we going to store the data (privacy)
How many users can access it simultaneously
What happens when a machine dies

Most of the work happens on the server side, where the data lives:

DB
Sharding (partitioning)
Caching
Replication
Consistency

Compute Intensive Applications

Challenge - heavy computation. These applications are CPU/GPU bound (computation ↑, data ↓).
Like - image processing, video rendering, ML model training, simulation, cryptography.

Worries

How fast can we compute
Can we parallelize the work
Reduce computational cost
Can we use a GPU instead of a CPU

Mixed Applications

Currently we have mixed applications too, which rely on both, like YouTube:

Data intensive - serving videos to users
Compute intensive - recommending videos

Tip - Ask, where is the time being lost? If time is lost in moving data, it's a data intensive feature. If time is lost in computation, it's a compute intensive feature.

Functional and Non-Functional Requirements

1. Functional - WHAT the system should do. Product features, the requirement list, all the features/functions of the application. For example in Amazon:

User can register
User can login
User can see products
Search products
Filter products
Add to cart, apply coupon, place order etc.
Make payment
Track order

2. Non-Functional - HOW the system should do it. Product properties, user expectations.

Example of Amazon (assume 1 million users):

Should handle 1 million users
Response time < 200ms
99.9% availability
Data encryption
Scalable up to 10x traffic (sales)

Common non-functional requirements:

Scalability - horizontal/vertical
Availability - uptime
Reliability - no data loss
Performance - latency
Security - authentication (who are you), authorization (what are you allowed to do), encryption
Maintainability - code modularity
Observability - monitoring and logging

Functional -> WHAT        Non-Functional -> HOW

DNS - Domain Name System

Ever wondered what happens when you type www.example.com in your browser and press enter? Computers don't understand names, they understand IP addresses (like 19.28.38.41). DNS is the phone book of the internet, it converts the name into the IP address. Explaining it in short:

First the browser checks its own cache, then the OS cache. If we visited the site recently, we already have the IP. Done, super fast.
If not, the request goes to the DNS Resolver (usually run by your ISP - Internet Service Provider, or something like Google's 8.8.8.8). It also has a cache, if the IP is there, it passes it back to the user.
Otherwise, the resolver hits the Root Server. There are 13 root server addresses in the world (with well over a thousand physical copies spread across the globe). The root doesn't know the IP, but it knows where the TLD - Top Level Domain server for .com, .in, .dev, .org etc. is.
Now we are redirected to the TLD server of the request, e.g. .com. This TLD server gives us the address of the Authoritative Name Servers of that website.
The authoritative name server finally gives us the IP address of our required server/site.
Now the request is made from the user to that IP address and the application is used. The resolver also caches it (for its TTL) for future use.

If nothing is cached, all 6 steps can take tens to a few hundred milliseconds, but most of the time step 1 or 2 already has the answer, so it's almost instant.

Cache levels

Remember our store counter analogy from the cache layer? Caching isn't only between the server and the DB, it happens at several levels:

Browser level
Operating System
DNS Resolver (already looked into)
Server side (Redis etc. between server and DB)

API - Application Programming Interface

APIs are the bridge which connects the frontend with the backend (or one application with another), and using this the applications work in real time. Now there are two types of APIs based on who can use them:

1. Access to another (Public / Third party APIs)

You must have come across platforms like Google Gemini, ChatGPT where you saw developer APIs, or IMDb APIs. These are public APIs maintained by these companies, and other developers can use them. Like with IMDb APIs you can look for movies, their ratings, cast, duration and show them in your own app. For this feature, some companies charge an amount, some keep it free.

2. Single App (Private / Internal APIs)

Here the APIs are for the application only, no public access. Like your own backend serving your React website and your Swift iOS app.

Types of APIs

1. REST - Representational State Transfer

The most widely used API style. It's light, gives freedom and is very easy to work with. Most modern applications use this. It mostly uses the JSON format. (REST is actually a set of rules/style on top of HTTP, not a format, JSON is just the most common choice.)

2. SOAP - Simple Object Access Protocol

It was widely used before JSON became popular and still a lot of legacy apps (old banking, enterprise systems) are using it. It uses XML, which is bulky in nature, and it has strict rules about everything from the header to the body. If an app wants to use these APIs, it has to handle the XML format, like a modern app consuming some old bank's APIs.

3. GraphQL - a query language for your API

This exposes a single API (endpoint) but a query language is attached. So the frontend asks for exactly the fields it needs. So instead of several APIs each responsible for a single task, we have a single API that does all of the work. We decide what data to choose and we get only that, nothing else. This saves bandwidth plus improves the response (no over-fetching or under-fetching).

4. gRPC (Protocol Buffers)

gRPC is developed by Google and uses Protocol Buffers to send data. Protocol buffers are a binary format, smaller than JSON/XML, that's why they are faster to transfer.

The downside - since it's binary, it's not human readable (you can't just open and read it like JSON), you need to define a schema (.proto file) first, and browsers don't support it directly. Therefore it's not great for browser-facing APIs, but it is a great fit inside a microservice architecture. Imagine several microservices talking to each other all the time, they just need small information to work on, there protocol buffers shine.

5. WebSockets

Best option for real time and persistent connections. In normal APIs, the client asks and the server answers, that's it. In WebSockets, the connection stays open and both sides can send data anytime (bi-directional). Widely used in chat apps where a constant connection is required. Chatting, multiplayer gaming, live scores and the live chat on a stream need WebSockets for real time bi-directional connection. But it is expensive to use, as every open connection eats server resources, and we need additional components to keep it alive since it stays on all the time.

RESTful APIs

Now we will be expanding on RESTful APIs as they are used widely in the industry. As mentioned, they use JSON to transfer data from one side to another. JSON holds data in key-value pairs, and a value can be a string, number, boolean, array or another object.

An endpoint for an API consists of two things:

Endpoint = Method + Path
           GET    + example.com/api/v1/resources

Methods in REST APIs

GET - used to get data from the backend
POST - used to send data from the frontend to create a new entry in the DB
PUT - used to update data in the DB, this replaces the whole object with the data passed
PATCH - also used to update, but this updates only the specified fields in the object
DELETE - used to delete the entry from the DB

Ways to Pass Data Through an Endpoint

Now there is a need to pass data from the frontend to the backend, how can we do it?

1. Path (Path Parameter)

We can directly use the path to pass data to the backend.
Example - example.com/api/v1/user/{id}
Here id is the placeholder for the user's id. Then in the backend we can read the id and use it to retrieve the data from the DB.
Good for - identifiers, like user id, item id, slugs. Also for clear relations by nesting, like user/comments/{id} or blog/{id}/comments.

2. Query Parameter

Here also we pass the data in the URL, but it comes after a ?, like example.com/blog?page=4&sort=asc.
Good for - filtering, sorting, searching, pagination. Remember it's exposed in the URL.

3. Body of request

In this we send the data inside the request body. The better option for big or sensitive data (passwords, forms etc.), it needs slight additional handling. It's not visible in the URL, so it doesn't end up in browser history or server logs. (The actual security comes from HTTPS, which encrypts the whole request.)

API Request Example

POST          /api/v3/users                                     => Method + URL
Content-Type: application/json                                  => Meta data (headers)
Body:         {"name": "Testing", "last_name": "Testing2"}      => Body

API Response Example from Backend

1. Status Code

It tells about the status of the request in a nutshell, like whether it was a success or not.

2xx - everything is fine
3xx - just redirecting to another place
4xx - something is wrong from your side (client)
5xx - something is wrong from the server side

Common ones:

200 - OK, success
201 - Created (after a successful POST)
400 - Bad request
401 - Unauthorized (who are you? login first)
403 - Forbidden (I know you, but you're not allowed)
404 - Not found
500 - Internal server error

2. Body

We also send a body in the response, that's how the frontend gets the data. We can send any type of data back, but a good rule of thumb is to always send the data wrapped inside an object, don't directly return an array or a plain value. This way future changes are manageable, tomorrow if you need to add pagination info or a message, just add a new key without breaking the frontend.

{
  "users": ["value1", "value2", "..."]
}

Bonus - The Five Step Framework

Whenever you sit to design any system (or face a system design interview), follow these 5 steps:

Clarify Requirements - functional and non-functional, what are we building and for how many users?
Data + APIs - what data do we store (SQL/No-SQL) and what endpoints do we need?
High Level Architecture - draw the boxes: frontend, LB, servers, cache, DB, MQ.
Scale & Edge Cases - replication, partitioning, caching, what if a server dies?
Wrap Up - summarise the trade-offs you made and why.

Quick Recap

System design is the plan before the code, components + a common goal.
Database - SQL for structure and transactions, No-SQL for scale and flexibility.
Server - the backbone, exposes the DB through APIs.
Frontend - what the user sees and touches.
Cache - small, fast, saves the DB from repeated reads.
Load Balancer - spreads requests across servers and keeps an eye on their health.
Replication & Partitioning - copy the data for availability, split it for size.
CAP - when the network breaks, choose consistency or availability.
Message Queue - do the not-so-urgent work later, asynchronously.
Monitoring - our work doesn't end at deployment.

That's System Design 101. Your next step: pick an app you use daily, like Instagram or Swiggy, and sketch which of these components it uses and where each one sits.

I hope you found it helpful.
Until next time.
Peace ✌️

AI 101 - A Beginner's Introduction to Artificial Intelligence

Blackwatch — Wed, 14 Oct 2026 17:42:47 +0000

You have probably used AI today, maybe even before getting out of bed. Unlocked your phone with your face? That's AI. Opened YouTube and it showed you exactly the video you wanted to watch? AI again. AI is everywhere around us, but what actually is it?? Let's understand it from scratch, no fancy maths, no complex words.

What Makes Humans Intelligent?

There are many factors, but two important ones are:

Autonomy - Freedom to act and take our own decisions.
Adaptability - Learning from experience and improving with time.

Artificial Intelligence

AI is the process of making computer programs intelligent, just like humans.

Similarly, the things which make a program intelligent are:

Autonomy - The program's ability to assist or work independently, without someone telling it every single step.
Adaptability - The program's ability to improve as it analyzes more data.

Example - Keyboard suggestions (Predictive text)

As we type, the keyboard suggests the most likely next words (working on its own) and keeps learning from each new sentence we type (adaptability). Ever noticed that after a while it starts suggesting your friend's nickname or the slang you use a lot? That's it learning from you.

Calculator

Not an AI tech. It can't operate on its own and can't learn from the user's input, it only does what it is asked to do. 2 + 2 will always be 4, no matter how many times you ask it.

AI vs Machine Learning vs Deep Learning

People use these words like they all mean the same thing, but they don't. Think of them as circles inside circles.

AI - The biggest circle. Any technique that makes machines act smart.
Machine Learning (ML) - A part of AI. Instead of telling the machine every rule, we let it learn from data.
Deep Learning - A part of ML that uses "neural networks", loosely inspired by how neurons in our brain are connected. It needs a lot of data and computing power, but it is behind things like face unlock, voice assistants and the AI chatbots we use today.

If you want to go deeper into these layers, check out my article Layers in AI.

How AI Can Be Useful for Us

It can reduce our workload
It can do our repetitive work for us
It can improve the quality of our work

Some real world uses

Farmers - Using AI based apps to check if their crops are healthy or not, or chatting with AI to improve their yields.
Doctors - AI helps in analyzing X-rays and scans, so doctors can find tiny signs of sickness or injury that might be hard to see.

AI you already use (without even noticing)

Netflix / YouTube - Recommending what to watch next
Google Maps - Predicting traffic and finding the fastest route
Face unlock - Recognizing your face to unlock your phone
Email spam filter - Keeping junk mail out of your inbox
Chatbots - ChatGPT, Claude, Gemini etc. answering your questions

Note - AI is a tool, and it's on us how we use it.

Algorithms

Ever wondered how we can teach technology to learn new things?? We are trying to make machines like us by giving them intelligence, but still they can't learn just like us. We learn from experiences, from patterns, etc. Machines don't have real world experiences, so how do they learn? For that, we have algorithms.

An algorithm, in a nutshell, is a set of step by step instructions to achieve or complete something.

Example - Make me tea

Boil the water
Add sugar and tea
Add milk
Let it cook for 5 minutes
Serve it hot

See, this is an algorithm too, detailed step by step instructions to make tea. Similarly, we use algorithms to train our programs so that they can understand things.

Normal Programs vs Machine Learning

Now here's the interesting part. In the tea example, we wrote every single step ourselves. That's how normal programs work, just like our calculator.

Normal program - We write the rules → the computer follows them.
Machine learning - We give examples → the computer figures out the rules on its own.

Let's say we want a program to tell if an email is spam or not. With a normal program, we would have to write every rule ourselves, "if it says FREE MONEY, mark it spam", "if it has 20 links, mark it spam" and so on. But spammers keep coming up with new tricks, we can't write rules for all of them.

With machine learning, we just show it thousands of emails marked as "spam" and "not spam", and it finds the patterns by itself. So here the algorithm's job isn't to make tea, it's to guide the machine on how to learn from the data.

Key Parts of Machine Learning

First let's understand how the human brain works. Let's take an example of "How you prepare for an examination".

Brain - The place where we store everything we learn.
Notes - We take notes for understanding and learning purposes.
Studying - Now we study those notes and start making connections between them, this is the adaptability we talked about.
Prepared Brain - Now the brain is trained to tackle most of the questions related to that subject.

Brain + Notes + Studying = Prepared Brain

Now coming to machine learning. Programs use mathematical instructions/operations to find patterns in data to make predictions.

Parts of Machine Learning

Model (Brain) - The storing and learning part of AI.
Data (Notes) - The data given to the model.
Training (Studying) - The model analyzes the data to find patterns among them and learn from them. There are different ways through which AI learns, we will see them in a moment.
Trained Model (Prepared Brain) - Now the model is ready to be used and make predictions.

Model + Data + Training = Trained Model

Training vs Using the Model

Training is the studying part. It takes a lot of time, data and computing power, and happens once (or from time to time to update the model). Using the trained model to answer questions or do tasks is called inference, it's like writing the exam. You don't re-study the whole book for every question, you just use what you already learned.

Features

In terms of AI, and in humans too, features are pieces of information that help us tell things apart. Take a circle and a square for example. How do you know which one is which?

Feature	Circle	Square
Corners	0	4
Straight sides	0	4
Curved edge	Yes	No

You never consciously think about this, your brain just does it. But a machine needs these features to tell them apart.

Same goes for our spam example. Features of an email can be - does it contain "FREE MONEY", is the sender unknown, does it have too many links. The model looks at these features and learns which combination usually means spam. The better the features, the better the model will understand.

Types of Learning

Remember we said there are different ways through which AI learns? Here are the three main ones.

1. Supervised Learning - Learning with flashcards

Remember the flashcards from childhood? A picture of an apple with "Apple" written below it. Here, the data comes with the answers (we call them labels). For example, thousands of emails already marked as "spam" or "not spam". The model learns from these and then predicts for new emails.

2. Unsupervised Learning - Sorting a pile of Lego

Imagine someone hands you a big pile of mixed Lego pieces and doesn't tell you anything. You will still start grouping them by color, size or shape on your own. Here the data has no labels, and the model finds groups and patterns by itself. For example, an online store grouping its customers by their shopping habits.

3. Reinforcement Learning - Training a dog with treats

When a dog does the right thing, it gets a treat. When it does the wrong thing, no treat. Slowly it learns what to do. Same way, the AI tries something, gets a reward or a penalty, and improves by trial and error. This is how AI learns to play games like chess, and how robots learn to walk.

Will AI Always Give the Correct Answer??

Now we can ask questions from the model or ask it to perform tasks. But the real question is, will it return the correct answer all the time??

The answer is no. There is always a possibility of AI producing a wrong answer, and most of the time it is because of the data provided. That's why the more data, and of good quality, the better the accuracy of the model.

Imagine a model trained only on the English language, and users are asking questions in their native language, like Spanish, Chinese, Hindi or Japanese. Do you think it will be able to produce correct answers?

Just for a moment, imagine yourself in this situation. Will you be able to answer a question asked to you in a language you don't understand??

It's just like the old story of the blind men and the elephant. Each one touches only one part and is sure he knows the whole truth. One says it's a snake, one says it's a wall, one says it's a rope. AI is the same, it only knows what its data showed it.

Image credit: Sketchplanations

And sometimes AI makes mistakes very confidently. Chatbots can give an answer that sounds totally correct but is completely made up, like a fake fact or a book that doesn't even exist. This is called hallucination. So remember, sounding confident doesn't mean being correct.

Bias

Remember how AI learns from the data we give it? So if the data is unfair, the AI will be unfair too. This is called bias.

Real example - Amazon once built an AI tool to screen job resumes. It was trained on resumes from the past 10 years, and most of those came from men, since the tech industry was mostly male. So the AI learned that male candidates are "better" and started ranking down resumes that had the word "women's" in them, like "women's chess club captain". Amazon had to scrap the tool.

The AI wasn't evil, it just copied the pattern from the data it was given.

Safety and Responsibilities

AI is now widely used and has become a part of our day to day life. But there are still risks in depending on it too much, because the possibility still exists that AI may not produce accurate results, which may lead to wrong decisions.

Imagine a medical model isn't trained on enough data. It can create false emergencies, saying a patient is sick although the patient is fine.

So it's always advised to check the AI's result ourselves, as a second check, to make sure no false result is delivered to the other side. There have been real cases of false arrests because of this. In 2020, Robert Williams in Detroit, USA was wrongly arrested because a facial recognition system matched his photo to a suspect's, and it was trusted without checking properly.

When mistakes happen, who is responsible, the AI or humans?

We need to understand one thing here, AI is just a tool, built by a human and used by a human. So ultimately the whole responsibility lies on humans. AI doesn't have feelings and emotions, it works on the data it is trained on. And who gives the data? Humans. Who uses the AI? Humans.

So we are responsible for whatever happens because of AI.

So how can we reduce the harm?

Now that's the question we need to look into. We can do it from two perspectives.

1. Developer/Creator of AI tools

As the creator of the tool, it's my responsibility to:

Feed high quality and diverse data for the AI to find patterns and learn from. High quality data helps in understanding, while diverse data reduces bias, which is really important.
Listen to users' feedback to improve on the go.
Be honest about the limitations of the tool.

2. User of AI tools

Do not trust the tool blindly. Always double check the output, as it may produce wrong results.
Always make sure you are using the tool for a good cause and not to harm others in any way.
If you find any bug or any place for improvement, give feedback to the creator so they can improve it.
Avoid sharing your personal details like passwords, bank details or ID numbers with AI tools, as your chats may be stored and even used to train the model.

Common Myths About AI

"AI thinks and feels like humans" - No. It finds patterns in data. It doesn't have feelings, and it doesn't understand things the way we do.
"AI is always right" - We just saw that it isn't. Wrong data, bias and hallucinations can all lead to wrong answers.
"AI will replace all jobs" - AI will change a lot of jobs and take over many repetitive tasks, but people who know how to use AI well will have a big advantage. Calculators didn't replace mathematicians.
"AI is something new" - The term "Artificial Intelligence" was actually coined back in the 1950s. It just became popular recently because we now have a lot more data and computing power.

Quick Recap

AI - Making programs intelligent, with autonomy and adaptability.
Machine Learning - A part of AI where machines learn from data instead of fixed rules.
Deep Learning - A part of ML that uses neural networks.
Algorithm - Step by step instructions to complete something.
Model - The "brain" that learns and makes predictions.
Training - The model studying the data to find patterns.
Inference - Using the trained model to answer questions.
Features - Pieces of information that help tell things apart.
Labels - The correct answers attached to the data.
Bias - When AI becomes unfair because of unfair data.
Hallucination - When AI confidently gives a made up answer.

What's Next?

Now that you know the basics, you can check out:

The 5 Layers Behind Every AI App - To understand the different layers of AI in depth.
Prompt Engineering - To learn how to talk to AI tools and get better answers from them.

AI is just a tool, a really powerful one. The more we understand it, the better we can use it, and the better we can make sure it's used for good.

This was a small walkthrough of AI and how it works. I hope you found it helpful.

Until next time.

Peace ✌️

The 5 Layers Behind Every AI App

Blackwatch — Wed, 30 Sep 2026 11:22:08 +0000

It's been some time since the introduction of AI and now it has become an essential part of our life, isn't it?

As a developer I can vouch for this. My day now starts with AI and ends with AI too 😁.

AI gave us the power to be a one man army, to do things which typically needed a whole team in the past. Now we can do those things on our own. Just a subscription to an AI model and we are done.

But things aren't this easy. To use AI to its full extent, we need to understand how it works.

As a human, the best thing we can do is give a well defined prompt, informative enough for the AI to understand our requirement, and it's good to have some examples of what we expect.

Then comes one of the most important parts in this, iterations. Even AI can miss some things, or what if you change your mind? That's why it's good to iterate until we reach the goal we set in our mind.

To write an effective prompt I already wrote an article, Prompt Engineering: How to Actually Get What You Want from AI. You can refer to this to improve your prompts.

Now taking one step further. In this article we will dive into AI's layers and understand the stack behind it.

One quick clarification before we start. I am not talking about the layers inside a neural network, the input and hidden and output ones. I am talking about the layers of the stack that every AI product you use is built on top of.

So, majorly there are five layers behind the AI tools we use today. We will go top-down, starting with what you see and ending with what it all runs on.

Gen AI Apps (Application Layer)
Agent Layer
Platform Layer
Models Layer
Infrastructure Layer

Now one layer at a time.

1. Gen AI Apps or Application Layer

User centric apps which the user uses to interact and work with AI

Have you worked with ChatGPT, Gemini, DeepSeek, Claude etc? Then most of the time you must have used some sort of app or the official website.

Here is the thing though. You are not talking to the model directly. There is an app sitting in between, managing your chat history, rendering the response, handling your file uploads. The model itself has no idea what a conversation is.

That app is the Gen AI app, and it is the layer the user directly interacts with.

2. Agent Layer

This layer utilizes the capabilities of the model layer to perform more complex actions. Think of them as digital workers with a brain.

You specify a task to them, they gather information from the user, interact with the environment to gather more information, make decisions, and execute actions based on the info received.

They differ from simple AI in the fact that they can actually do the work. Like searching on the internet to look for the best restaurant, checking your schedule for free time, booking the table, and sending a mail or message to the other party for the invitation. Rather than just giving you the steps, it actually does the work.

This is the agent layer.

3. Platform Layer

This is one of the most important layers in AI. It acts as a bridge between the models and the layers above.

Here is the problem it solves. A trained model on its own is just a huge file of numbers sitting on some machine. It has no way for you to reach it, no idea who you are, and no way to handle a thousand people asking it things at the same time.

The platform layer is everything that turns that file into something an app can actually call.

So what does it actually do?

APIs — it gives you an endpoint to hit. This is the thing that makes a model usable from your code instead of just from a website.
Authentication — it checks who you are. This is where your API key comes in, and it is also how the provider knows which account to bill.
Rate limits and quotas — it decides how much you are allowed to use, and how fast. Anyone who has seen a 429 error while building with AI has met this part of the layer.
Routing and scaling — your request has to land on a machine that has a free GPU. The platform picks one, sends your request there, and spins up more machines when traffic goes up.
Monitoring and logs — it keeps the record. How many tokens you used, how long the request took, what failed and why.
Extra tooling — most platforms also give you the surrounding pieces, like vector databases for storing your own data, guardrails to filter unwanted output, and tools to evaluate or fine tune a model.

An example

Remember the restaurant agent from the last layer? Let's see what the platform does while that agent is working.

The agent decides it needs to think about your request, so it sends it to a model. That request hits an API endpoint. The platform checks your API key, confirms your account is allowed to use that model, and checks you haven't crossed your rate limit.

Then it finds a machine with a free GPU and sends your request there. The model does its thing and the answer comes back. On the way out, the platform counts the tokens you used, writes it to your usage log, and bills your account.

The agent gets its answer and moves on to the next step. All of that happened in between, and neither you nor the agent had to think about it.

Some platforms you may have heard of are Amazon Bedrock, Google Vertex AI and Microsoft Foundry, along with the APIs that the model providers run themselves.

If you have ever built a backend, this layer will feel familiar. It is the same set of concerns you already deal with every day, auth, rate limiting, scaling, logging. The only difference is that there is a model at the other end instead of a database.

4. Models

The elephant in the room, the brain of any AI. These give the power to AI to do the things that they are able to do nowadays, from simple conversations to generating videos.

There are different types of models as per the user's requirement.

LLMs (Large Language Models) — good for conversations or text based things. From translation to creating mails for you.
Diffusion Models — LLMs are good for text, meanwhile diffusion models are for generating new media. They start from random noise and refine it step by step until an image or a video comes out.

5. Infrastructure Layer

We talked about most of the things, but all these things need infrastructure to run.

That physical part comes under this layer, from CPUs to GPUs to RAM and networking.

We can blame this layer for the increasing RAM and SSD prices currently.

Conclusion

So the next time you type something into a chat box, remember how much is sitting underneath it. Your message passes through the app, the agent and the platform, and then it gets turned into actual math running on actual hardware.

Five layers. The model gets all the attention, but it is only one of them.

This is a small guide on the layers behind AI. I hope you found it helpful.

Until next time.

Peace ✌️

Prompt Engineering: How to Actually Get What You Want from AI

Blackwatch — Tue, 08 Sep 2026 15:31:56 +0000

You ask an AI to help you prepare for an interview. You get back twenty generic questions you could have found on any blog.

You ask again. This time you mention that you are an entry-level developer, that you know the MERN stack, and that you want the answers in a table. Suddenly it is useful.

Same model. Same knowledge. Different prompt.

That gap, between the generic answer and the useful one, is what prompt engineering is about.

Prompts, and why they matter

AI has been with us far longer than most people realise. Ever wondered how your mobile keyboard suggests the next word while you are typing? That is AI too, just a very narrow use case of it.

Compare that with today's AI, which can answer our day-to-day questions, help with our tasks, generate articles, taglines and summaries, and even produce images and video, all from a simple text instruction.

That instruction is known as a prompt.

Now take a child as an example. When they are young, they speak gibberish which is hard to understand. But as they grow up, they communicate better, and it becomes easier to understand what they want.

A similar idea applies to Generative AI. If our instructions are unclear, the AI may misunderstand our requirement and produce a result that is off-target, irrelevant, or incomplete.

So how do we communicate with AI more effectively?

That is where prompt engineering comes in.

What is Prompt Engineering?

Prompt engineering is a method of writing prompts in a structured manner so that we provide the AI with the required information, relevant context, examples, and clear instructions.

This helps the AI generate a result that is closer to our expectations.

We can also use prompt chaining, where we break a big task into steps and feed the output of one prompt into the next.

Although there isn't one specific rule for creating the perfect prompt, a structure taught in Google's prompting course that may be useful is TCREI:

T — Task
C — Context
R — References
E — Evaluate
I — Iterate

Let's understand each of them.

Task

This is where we specify the task we want the AI to perform.

It can be:

Generate a report
Create a tagline
Analyze data
Write an email
Create a presentation

The task is the main instruction, the one thing you want the AI to do.

It can also have two additional parts.

Persona

Here we associate a role or personality with the AI, so that it approaches the task from that perspective.

For example:

Assume you are a software developer with 15 years of experience.

Or:

Assume you are a store manager with 10 years of experience.

A persona reliably changes how the answer is written: the vocabulary, the depth, and what the model assumes you already know. "Explain this as a senior developer would" and "explain this as a teacher would" produce genuinely different answers.

What a persona does not do is make the model know more. "You are an expert cardiologist" does not add medical knowledge it did not already have. Use a persona to shape the framing, not to buy accuracy.

Format

It is also a good idea to specify the format in which we want the result.

For example:

Give me a table with five points.

Or:

Provide the answer in three paragraphs.

Or:

Format the output as CSV with the columns: Question, Topic, Difficulty, Answer.

This helps us get an output that is more useful and closer to what we actually need.

Context

Context is important for AI because it helps create the background related to the task.

It is just like the background we provide before narrating a story to someone.

Imagine this prompt:

Analyze the given data and generate a profit and loss summary.

Good. But it only tells the AI what to do. It doesn't tell it much about the situation.

Now consider this:

Here is a company's sales data for the last year, including revenue, purchases, salaries, and other operating expenses. Analyze it and give me a profit and loss summary as a table.

Here we have also provided a background related to the task. This makes the requirement more specific and gives the AI additional information it can use.

Prompt 2 gives the AI something to work with. Prompt 1 makes it guess.

References

"References" actually covers two different things, and they are worth separating.

One is examples, where we show the pattern we want. The other is source material, where we paste in the actual document, spec, or data the answer should come from.

The second one is powerful. The model cannot make up an answer if you hand it the real one.

Let's look at examples first, since that is where most of the technique lives.

Instead of simply saying:

Explain React.

We can provide an example of the expected format:

Define React → Answer
How React works → Answer
What is ES6 → Answer

Now the AI has a reference for how we want the output to look.

There are different variants of prompting based on how many examples we provide.

Zero-Shot Prompting

In this approach, we don't provide any example. The AI has to rely on its pre-trained knowledge and the instruction we gave it.

For example:

Explain what React is in simple terms.

There is no example here.

Zero-shot works well for simple, direct questions and everyday tasks. When the output isn't coming back in the shape you want, that is the signal to start adding examples.

One-Shot Prompting

In this approach, we provide one example in the prompt. The example acts as a blueprint for the desired output.

For example:

Convert the following sentence into a professional tone.

Example:
"Hey, send me the report ASAP." → "Please share the report at your earliest convenience."

Now convert:
"Hey, fix this issue quickly."

Here the AI can understand the expected transformation from the single example.

Few-Shot Prompting

In this case we provide multiple examples so that the AI can identify the pattern and generate the expected output.

For example:

React → Frontend Library
Express → Backend Framework
MongoDB → Database
Node.js → ?

The AI picks up the pattern and answers "JavaScript Runtime".

Though watch out for something here. My three examples were all library, framework and database, so a model following that pattern too literally might answer "Backend Framework", which is wrong. Node.js is a runtime.

That is the real risk with few-shot: examples don't just show the format, they bias the answer. Choose examples that cover the range of answers you actually expect.

One more thing on quantity. Providing irrelevant or contradictory information hurts, because the model has no way to know which parts to trust. But good examples generally don't. The old advice was "two to five examples, no more", and that was reasonable when context windows were small. With today's much larger context windows, more consistent examples usually help rather than hurt.

So the goal is not fewer examples, and not more examples. It is consistent, relevant examples.

Evaluate

By this point we have the output generated by the AI.

Now our task is to evaluate whether it meets our requirements and follows the instructions in the prompt.

This is a crucial stage. We should check things like:

Did the AI perform the correct task?
Did it follow the requested format?
Is the information relevant?
Is anything missing?

And the one that matters most:

Is it actually correct?

A well-formatted, on-topic, confident answer can still be wrong. If the output contains facts, figures, version numbers, or API details you are going to rely on, check them somewhere else.

This evaluation becomes especially important when we continue the conversation using the generated result as context. If we don't identify problems early, we end up building on an incorrect result.

Iterate

Now we have evaluated our result. If the result is what we wanted, we are done.

But if something went wrong, this is where we correct the AI. We tell it what went wrong and what we want instead.

For example:

The format is correct, but you included unnecessary technical details. Keep the explanation beginner-friendly and limit it to five points.

This also gives us an opportunity to improve our own prompt, because sometimes the problem is not with the AI. Sometimes we simply didn't provide enough information, context, or clear instructions in the first place.

So prompt engineering is also an iterative process.

A Practical Example

Let's put everything together.

Suppose I am preparing for a frontend interview. I could give the AI a prompt like this:

You are a senior software developer with 10 years of experience.

I want you to help me prepare for my upcoming frontend interview. I am an entry-level developer with MERN stack experience and basic AWS knowledge.

List the questions I am most likely to be asked based on current frontend interview trends.

Format the output as CSV with the columns: Question, Topic, Difficulty, Answer.

Use the following examples to understand the type of questions I am looking for:

Define React → Answer
How does React work? → Answer
What is ES6? → Answer

Now look at what we have included:

Persona: Senior software developer with 10 years of experience.

Task: Help with frontend interview preparation.

Context: Entry-level, MERN expertise, basic AWS knowledge.

Format: CSV with specific columns.

References: Examples of the expected questions.

Now notice one weak spot in my own prompt. I asked for "current trends". Unless the tool I am using has web search turned on, the model has no idea what is current. It will produce something plausible from its training data and present it confidently.

This is exactly the EVALUATE step doing real work. I should either turn on web search, paste in a few recent job descriptions as source material, or drop the word "current" and accept that I am getting general fundamentals.

That is the whole idea.

A Few More Things That Help

The TCREI structure covers the bulk of it, but a few smaller habits make a noticeable difference.

Separate your instructions from your data. If you are pasting in a long document, wrap it so the model knows where your instruction ends and the content begins:

Summarize the document below in five bullet points.

--- DOCUMENT ---
(paste here)
--- END DOCUMENT ---

Without a separator, the model can read your pasted content as part of the instruction.

Say what you want, not what you don't. "Don't use jargon" performs worse than "use plain language a first-year student would understand." Positive framing consistently beats negative framing.

"Think step by step" is no longer a universal trick. It used to be the single most-cited prompting tip. On today's reasoning models, which already work through problems internally, it is often redundant and can occasionally make things worse by forcing a rigid structure. Try the prompt without it first.

Conclusion

Prompt engineering is not about writing extremely complicated prompts.

It is about communicating clearly with AI.

The more clearly we communicate our task, context, references, expectations, and desired format, the easier it becomes for the AI to produce a useful result.

TCREI is one framework that can help us structure that communication:

Task → Context → References → Evaluate → Iterate

And whatever the prompt, always verify the parts you are going to rely on.

This is a small guide on prompt engineering. I hope you found it helpful.

Until next time.

Peace ✌️

Top Frequently Used AWS Services: A Beginner-Friendly Guide

Blackwatch — Sun, 09 Aug 2026 12:02:31 +0000

AWS is one of the most popular cloud platforms out there and is used widely. The thing is, AWS comes with 200+ services, and knowing all of them is quite a big task on its own.

But for the majority of users, they are only going to use a handful of services most of the time. The aim of this article is to give a brief idea about those services.

In case you are already a champ in AWS, then you can also use this as a quick revision.

Once you log in to your AWS account, you will see a dashboard looking like a space shuttle operating system. So many things to look at.

But trust me on this one, you are majorly going to use the SEARCH bar to navigate through different services.

On the same nav bar, you will see REGION, which is a drop-down list of regions available to choose from.

These are actual AWS regions. Assuming you created some service in Region A, then you have to select that region to work with it. If you choose any other region, that service won't show up there.

So, make sure you remember which regions you are working in.

Otherwise, it may happen that you spin up a service in Region A and completely forget about it.

But the AWS billing team will not forget it. They will still charge you for it. 🙂

Now let's start with our services.

1. IAM — Identity and Access Management

Imagine you are running a team of 20 people, including interns.

Now you want to give access to your company's AWS account to other users. Here you can't just pass down your root credentials, because then that person could potentially have full access and authority to do whatever they want.

For that, we have IAM.

IAM is used to control who can access your AWS resources and what they are allowed to do.

Here we can work with users, groups, roles and policies.

For example, I don't want an intern to have permission to manage a database. But I want them to access database logs.

So, I can assign the appropriate permissions/policies to that user or group.

Now I don't have to worry about them accidentally doing something they shouldn't.

Even if you are working on a solo project, you should avoid using the root account for everyday work and use appropriate IAM access instead.

AWS permissions can get complicated very quickly, but the basic idea is simple:

IAM = Who can do what?

2. EC2 — Elastic Compute Cloud

"Virtual servers in the cloud."

In any cloud, we need servers where we can do our tasks. It can be running something on the cloud, deploying projects, hosting an API, running a backend, etc.

These are virtual machines and AWS calls them EC2 instances.

We can create multiple EC2 instances, subject to AWS service quotas. And remember, these are billed resources; they aren't just free machines sitting there waiting for you.

If you are eligible for a free tier offer, some instance types/usage may be covered depending on the current AWS terms.

The good thing is the flexibility AWS provides.

From choosing the operating system to choosing the type of machine, storage, networking and other configurations, we get a lot of control.

These machines come in different sizes and configurations. From a small machine enough to run a simple application to powerful CPU/GPU instances for demanding workloads.

Then we can configure the storage as per our needs.

If you aren't using a free offering and your instance is billable, running the instance can incur compute charges based on the instance type and pricing model you choose.

Security Groups

Now comes the concept of Security Groups for EC2 instances.

Here we can specify which ports and traffic are allowed to reach our instance and which outbound traffic is allowed.

It works somewhat like a firewall for our instance.

For example, we might allow:

Port 22 for SSH
Port 80 for HTTP
Port 443 for HTTPS

And block everything else that isn't needed.

Elastic IP

The moment an EC2 instance is spun up, it can have a public IPv4 address through which it can be accessed.

Now the thing is, the public IPv4 address can change when the instance is stopped and started.

For that, we have Elastic IP.

It provides a static public IPv4 address that we can associate with an AWS resource.

But there is one important thing to keep in mind:

AWS charges for public IPv4 addresses, including public IPv4 addresses associated with resources. So don't allocate addresses you don't actually need.

Load Balancer

Imagine we have several EC2 machines running, but users' requests are hitting only one machine.

This will create issues because each machine has limited capacity to cater to users. All requests hitting a single machine can overwhelm it and the machine may eventually crash.

For that, we have a Load Balancer.

Its job is to distribute incoming traffic across multiple healthy machines according to the configured routing rules.

So no single machine has to do all the heavy lifting.

For example:

                Users
                  |
            Load Balancer
             /     |     \
            /      |      \
         EC2 #1  EC2 #2  EC2 #3

Auto Scaling

Now imagine only 5 machines are being used for a project.

But suddenly traffic increases.

If the existing machines aren't enough to handle the extra requests, Auto Scaling can automatically launch additional EC2 instances according to predefined scaling policies.

And when the load decreases, it can reduce the number of instances again.

The important part is that we have to define these scaling rules beforehand.

For example:

If average CPU usage goes above 70%, add more instances.

And when the traffic comes back down:

If the load stays low, remove some instances.

The best thing about EC2 is the flexibility given to the user to create and configure their own machines.

From operating system to storage to networking and security, there is a lot in the user's hands.

3. S3 — Simple Storage Service

S3 provides a storage solution on the cloud provided by AWS.

Now we have deployed our project on EC2, but where will we store our data?

On the same EC2 machine?

No.

For that, we have S3 buckets.

Think of S3 as highly scalable object storage on the cloud.

We can manually store data in it or we can do it programmatically too.

We can store things like:

Images
Videos
PDFs
Backups
Logs
Application files
Static website assets

We can also control who can access the objects using IAM policies, bucket policies, access controls and other mechanisms.

For example, an object could be private and accessible only through authenticated access or a pre-signed URL.

One important thing to remember:

Creating a bucket doesn't mean you're suddenly paying for a giant storage drive.

You are primarily charged based on things such as the amount of data stored and requests/data transfer depending on the usage and storage class.

The beauty of S3 is that it is highly scalable and designed to store huge amounts of data.

Also, the name of a general-purpose S3 bucket has to be globally unique within the AWS partition.

No two general-purpose buckets can have the same name in that namespace, even if they are in different AWS regions.

4. ECR — Elastic Container Registry

Prerequisite — Docker

Since Docker is now widely used in the development world, and it makes sense too because it makes development and deployment relatively easy.

Now, if you have knowledge of Docker, then you must know about Docker Hub.

It is a container registry where we can push and store our Docker images.

The same basic idea is provided by Amazon ECR, but it is part of AWS.

We can push our Docker images to ECR and then use those images with AWS services such as ECS and EKS.

So ECR primarily does two things:

Stores our container images.
Makes those images available for our AWS container workloads.

For example:

Dockerfile
    ↓
Docker Image
    ↓
   ECR
    ↓
ECS / EKS
    ↓
Running Container

Same as S3, the cost is primarily related to things like storing and transferring images rather than simply creating a repository.

5. ECS — Elastic Container Service

Running an image creates a container.

Now, once the container is up and running, we need to manage it.

For that, we have ECS.

ECS is AWS's container orchestration service. It makes it easier to run, stop, manage and scale containers.

For example, imagine you have an application running inside a Docker container.

You don't want to manually log into a server every time you need to:

Start a container
Stop a container
Run multiple copies
Replace a failed container
Scale the application

ECS helps manage all of this.

It can work with other AWS services to handle things like load balancing, service discovery and scaling.

For example, if traffic increases, ECS can run more copies of your container.

If a container fails, ECS can start a replacement according to the configuration you provide.

So instead of manually managing individual containers, ECS manages them as part of a service.

6. EKS — Elastic Kubernetes Service

Now we have ECS.

But what if you already know Kubernetes and want to use Kubernetes on AWS?

Enter EKS.

EKS is AWS's managed Kubernetes service.

If you already know Kubernetes, then much of your existing Kubernetes knowledge, YAML manifests and tooling can be used with EKS.

AWS manages the Kubernetes control plane for you, while you still get the Kubernetes ecosystem and flexibility.

So a very simple way to remember this:

ECS → AWS's container orchestration service
EKS → Managed Kubernetes on AWS

If you don't want to deal with Kubernetes and want something more AWS-native, ECS can be a simpler choice.

If your team already uses Kubernetes or needs the Kubernetes ecosystem, EKS can make more sense.

7. VPC — Virtual Private Cloud

Now we have EC2, RDS, load balancers, containers, etc.

But where do all these resources actually live?

That's where VPC comes in.

VPC allows us to create our own private network inside AWS.

We can control things like:

IP ranges
Subnets
Route tables
Internet access
Private/public networking
Network-level security

For example, imagine we have a web application.

We can put the application/load balancer in a public-facing part of the network while keeping our database in a private subnet.

So users can access the application, but they can't directly access the database from the internet.

A very simple mental model:

                Internet
                   |
             Load Balancer
                   |
             Application
                   |
              Private DB

VPC becomes extremely important once your application starts becoming more than just a simple server.

For now, just remember:

VPC = Your private network inside AWS.

8. Lambda

Okay, we talked about EC2.

But what if I don't want to manage a server at all?

That's where AWS Lambda comes in.

Lambda allows us to run code without managing the underlying servers ourselves.

For example, imagine you have an application where a user uploads an image to S3.

You want to automatically resize that image after it is uploaded.

Instead of keeping an EC2 server running 24/7 just for this task, you can trigger a Lambda function whenever a new image is uploaded.

User uploads image
        ↓
       S3
        ↓
     Lambda
        ↓
Image gets resized

AWS handles the underlying compute infrastructure and the function runs when it is invoked.

So a simple way to remember it:

EC2 → You manage the server
Lambda → AWS manages the underlying server infrastructure

Lambda is especially useful for event-driven workloads, APIs, automation and small pieces of backend logic.

9. CloudWatch

Since now we have talked about several services that AWS offers, how do we know if they are working the way they are supposed to?

How do we check if a server failed or is facing some issue?

For that, we have CloudWatch.

CloudWatch is AWS's monitoring and observability service.

It can work with things like:

Metrics
Logs
Alarms
Dashboards
Application monitoring

We can also set alarms.

For example:

If CPU usage of an EC2 instance stays above 80% for 5 minutes, trigger an alarm.

Or:

If the number of errors suddenly increases, notify the team.

We can also use CloudWatch to monitor application logs and help developers pinpoint issues customers are facing.

So remember:

CloudWatch → What is happening with my applications and AWS resources?

10. CloudTrail

Now imagine someone created a new database.

Or someone spun up 20 EC2 machines.

Or an intern deleted an entire database. 💀

Now how do we see who did this?

For this, we have CloudTrail.

CloudTrail records activity in your AWS account, including actions performed through the AWS Management Console, CLI, SDKs and AWS APIs.

So we can use it to investigate things like:

Who created this resource?

Who deleted it?

When did they do it?

Which API call was made?

This becomes extremely important when multiple people are working on the same AWS account.

So the easiest way to remember the difference is:

CloudWatch → What is happening?
CloudTrail → Who did what?

11. RDS — Relational Database Service

Now our application is up and running.

But we don't have a database to store our data.

For that, we have RDS.

RDS stands for Relational Database Service and it is a managed service for relational databases.

We can choose from multiple database engines depending on our requirements.

We can configure things like:

Database engine
Instance size
Storage
Networking
Backups
Availability
Security

The good thing is that AWS manages a lot of the underlying database infrastructure for us.

For example, instead of manually setting up a PostgreSQL database on an EC2 machine and then worrying about backups, patching and other maintenance tasks, RDS can handle many of those responsibilities for us.

One thing to keep in mind:

RDS can become a significant part of your AWS bill, depending on the instance, storage, backups, availability configuration and other options you choose.

12. DocumentDB

Need a document database?

That's where Amazon DocumentDB comes in.

DocumentDB is AWS's managed document database service and provides MongoDB compatibility.

So if you're coming from the MongoDB world, many concepts will feel familiar.

But one important thing:

DocumentDB isn't simply MongoDB running on AWS.

It is a separate AWS service with MongoDB compatibility and there are differences between the two.

For now, the simple thing to remember is:

RDS → Relational databases
DocumentDB → Document database

13. ElastiCache

You might think databases are done.

But what about one more important thing?

Caching.

Sometimes we don't want to repeatedly query our database for the same data.

Imagine your application has a popular product page.

Thousands of users are requesting the same product information.

Instead of hitting the database every single time, we can keep frequently accessed data in a cache.

That's where Amazon ElastiCache comes in.

It is AWS's managed caching service and supports caching engines such as Valkey and Memcached.

For example:

User
 ↓
Application
 ↓
Is data in cache?
 ↙          ↘
YES          NO
 ↓            ↓
Cache       Database
              ↓
           Save in cache

Cache is generally much faster to access than going all the way to the database.

So remember:

RDS → Store your application's data
ElastiCache → Keep frequently accessed data ready for fast access

That's pretty much it!

These are some of the AWS services that you are likely to encounter frequently when building and deploying applications.

Obviously, AWS has a lot more services than these.

But you don't need to memorize every single AWS service before you can start building things.

Start with the services you actually need and learn the others as you encounter them.

For a quick revision, here is a simple cheat sheet:

AWS Service	Think of it as
IAM	Who can access what?
EC2	Virtual server
S3	Cloud object storage
ECR	Docker image registry
ECS	AWS container orchestration
EKS	Managed Kubernetes
VPC	Your private network in AWS
Lambda	Run code without managing servers
CloudWatch	Monitoring and observability
CloudTrail	Who did what in your AWS account
RDS	Managed relational database
DocumentDB	Managed document database
ElastiCache	Managed caching

And that's it.

I tried to keep these explanations small enough for quick revision, but detailed enough to give you an idea of what each service actually does.

Hopefully, this helps you understand AWS without feeling like you have to memorize an entire spaceship control panel. 🚀

I hope you liked it!

RIVAL — I Built an AI That Settles Any Rivalry… Out Loud 🔥

Blackwatch — Mon, 13 Jul 2026 05:56:26 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

Remember being a kid and staging the ultimate showdowns in your head? Goku vs Naruto. Gohan vs Batman. Your dog vs the neighbour's cat. No rules, no logic — just pure "who would win?!" chaos with your friends until someone rage-quit.

RIVAL is me trying to bottle that feeling.

You type in any two rivals — real or fictional, living or non-living, serious or completely ridiculous — pick a tone, and smash the 🔥 IGNITE button. RIVAL then:

writes a fiery, over-the-top hype monologue that trash-talks and celebrates both sides,
scouts each contender with 💪 Powers and ⚠️ Weaknesses cards,
crowns a winner and drops a bold prediction,
rates the beef on a passion meter,
and — the best bit — reads the whole thing out loud like a dramatic sports commentator.

Barça vs Real Madrid, settled. (The AI sided with Madrid. I'm choosing not to comment.)

⚠️ Please don't take the verdicts to heart. It's a fun project, not a court ruling. I asked it to settle Batman vs a cat and… let's just say I'm still not over the result. 🥲

That's the whole idea: pick two things, start a fight, enjoy the show.

Demo

🔴 Try it live: https://rivals-tau.vercel.app/

Watch it in action (turn the sound ON — the voice is the whole point):

And here's the setup — two rivals, six quick presets, five tones, one big red button:

Code

BlackWatch021 / Rivals

My submission for dev.to weekend challenge

🔥 RIVAL

Settle the rivalry.

Pick any two rivals — real or fictional, living or non-living, serious or completely ridiculous. RIVAL writes fiery trash-talk, scouts each side's powers & weaknesses, crowns a winner, and then reads the whole thing out loud like a dramatic sports commentator.

🔴 Live Demo · 📖 Read the story · 🎬 Watch the demo

✨ What it does

🥊 Any matchup — Goku vs Naruto, iOS vs Android, Cats vs Dogs, Coffee vs Tea… if you can name two things, you can pit them.
✍️ Fiery AI monologue that trash-talks and hypes both sides.
💪 Scouting cards — Powers & Weaknesses for each contender.
🏆 A winner + a bold prediction, plus a passion meter for the beef.
🎙️ Dramatic spoken commentary — the verdict, read aloud.
🎭 Five tones — Hype, Savage, Sarcastic, Professional, Wholesome.
⚡ Six…

View on GitHub

How I Built It

The plan sounded easy: "call two AI APIs, done by lunch." Reader, it was not done by lunch. Here's the fun of it.

🧱 The stack

Next.js (App Router) + TypeScript + Tailwind, deployed on Vercel. Two tiny server-side Route Handlers do all the secret-key work — /api/generate for the text and /api/voice for the audio — so my API keys never touch the browser. The frontend only ever talks to my server, and my server talks to the AIs. No key ever ships to the client.

🧠 The brain — Google Gemini

Gemini does all the writing: the monologue, a shorter spoken version, the powers/weaknesses for each side, the winner, the prediction, and a passion score — all returned as clean JSON, and all steered by whichever tone you picked (Hype, Savage, Sarcastic, Professional, Wholesome).

Cats vs Dogs. "Silent assassins" vs "Separation anxiety." Chef's kiss.

My first attempts kept returning cut-off, broken JSON, and it drove me up the wall. Turns out the model I'm on is a thinking model — it was quietly burning its entire token budget "thinking" and running out of room mid-sentence. The fix was to tell it to stop overthinking and just answer:

generationConfig: {
  responseMimeType: "application/json",
  thinkingConfig: { thinkingBudget: 0 }, // stop pondering, just reply
}

Sometimes the AI just needs to be told to shut up and hand over the goods.

🔊 The voice — ElevenLabs

This is the "wow." ElevenLabs takes the text and reads it back in a dramatic broadcaster voice. I feed it a tight, ~40-second spoken version instead of the full monologue, so it lands like a punchy highlight reel instead of a two-minute TED talk.

Gotcha I learned the hard way: on the free tier you can't use ElevenLabs' fancy "library" voices through the API — it throws a payment error right in your face. Swapping to a built-in premade voice ("Daniel", a steady broadcaster) fixed it and honestly suits a commentator better anyway.

💸 Surviving the free tier (a.k.a. the real project)

Here's the twist nobody warns you about: I'm on the free tier of both AIs, and that quietly became the most interesting engineering constraint of the whole build.

Gemini gives me roughly 20 requests a day. ElevenLabs gives about 10,000 characters a month — that's ~5 full monologues. Not a lot once strangers on the internet start hammering IGNITE.
So that short spoken version isn't just nicer to listen to — it's about 4× cheaper on characters (≈2,000 → ≈340 per go).
The six preset matchups are pre-generated (text and audio) and served as static files. Clicking a preset costs zero API calls — instant, free, and infinitely replayable. That's the guaranteed-to-work demo path.
And when a quota does run dry, you don't get a scary red error — you get a cheeky popup, and the app gently nudges you toward a preset instead. Failing with a smile beats failing with a stack trace.

The most polite "I'm broke, please try a free one" message I could write.

Prize Categories

Best Use of Google AI — Gemini writes every word: the trash-talk, the scouting report, the verdict, and the prediction, tuned to whatever tone you pick.
Best Use of ElevenLabs — it turns all of that into dramatic, spoken-word commentary that plays right on the page.

Built solo, over one caffeine-heavy weekend. 🔥

I had a whole list of features I didn't get to (I started late — classic), so if RIVAL made you smile and you'd like to see it grow, drop a comment with your dream matchup or the feature you'd add — I'm reading every single one.

Now go settle something ridiculous. Batman deserves a rematch. 🦇🐱

Your Node.js Server is Using Just One CPU. Here's How to Fix It.

Blackwatch — Sun, 24 May 2026 06:10:34 +0000

CLUSTERING

You created your node application, it's ready, you have chosen an 8 vCPU instance to deploy it. You are done with deployment. Everything is working fine, but unknowingly you aren't using the full potential of the deployment. We know that node.js runs on a SINGLE THREAD, which means our node application uses only one vCPU at a time — but you took an 8 vCPU instance, so aren't the other 7 vCPUs sitting there idle?

The solution for this is CLUSTERING. It's a concept of running multiple instances of an application, where each works as an individual entity but still gets the work done and runs on the same port. Now the question is — how will this work? Isn't it going to cause issues among the instances? The simple and short answer is no.

HOW IT WORKS

When clustering is done, we end up with multiple processes. There are two kinds:

Primary – There is only one primary. It is responsible for spinning up the worker processes, managing them, and if any one of them dies, spawning it back. The primary is there only to manage — it doesn't run the code (connecting with db, spinning up server, etc.) Note – If the primary is down, the entire cluster will crash.
Workers – These are the actual instances where the application runs — they serve the users.

Key Facts

Since there are 8 vCPUs in our case, there will be 9 total processes — 1 primary + 8 workers.
Each worker has its own memory – nothing is shared among workers.
Workers share a single port – connections are distributed across them.
Primary is intentionally dumb – never runs code or connects with db.
Workers can't see their siblings — for each worker, only itself exists.

CODE SNIPPET

import cluster from "node:cluster";
import os from "node:os";
import app from "./src/app";
import { connectDB } from "./src/config/database";
import { createServer } from "http";

const PORT = process.env.PORT || 3000;
const enableCluster = process.env.NODE_ENV === "development";

if (enableCluster && cluster.isPrimary) {
  const numWorkers = os.cpus().length;
  for (let i = 0; i < numWorkers; i++) cluster.fork();

  cluster.on("exit", (worker) => {
    console.log(`worker ${worker.process.pid} died — respawning`);
    cluster.fork();
  });
} else {
  const httpServer = createServer(app);
  connectDB().then(() => httpServer.listen(PORT));
}

EXPLANATION OF CODE
In production we generally use services like pm2 to manage clustering, but here we are doing it using native options. For that, we first need the cluster and os modules of node.
Then we check if the current process is the primary or not. If it is the primary, we spawn new workers as per the number of cores available — it's not hard coded, we may change it as per our convenience, but it should not be more than the number of cores/vCPUs. If it isn't the primary (meaning we are already inside a worker), we run the actual backend code — connecting to the DB and starting the server. So now we have 8 worker instances up and running (plus the primary watching over them).
Using process.pid, we can see the unique id of each worker.
Note – this id, and whatever happens inside an instance, stays there only. Other instances can't access this one's data, process, etc.

PROS/CONS

Pros:

Uses all CPU cores
Crash isolation
Built into Node
Higher throughput, CPU-bound work
Auto-respawns dead workers

Cons:

Each worker has its own RAM (no shared state)
In-memory caches/sessions break silently
WebSockets/SSE need extra infrastructure
Harder to debug – 'which worker logged that?'
Primary crash = whole cluster dies

Note – load balancing is round-robin on Linux; on Windows, the OS decides routing.

BIG CAVEAT

This much is enough for simple clustering or for learning purposes, as long as our app is using stateless data (REST APIs backed by a DB).

In this case, the DB is the source of truth. Workers don't need to know about each other. Any worker can serve any request.

STATEFUL connections (WebSocket)
Prerequisite — knowledge of websockets.

Now things change. Once a connection is established and the HTTP request is upgraded to a WebSocket, the socket connection details (which user is on which socket) are stored in memory, inside that worker. So if User A connects through Worker 1 and User B connects through Worker 2, both are logged in and both users' data is stored in the DB. But the live sockets sit on different workers. Now when A sends a message to B, Worker 1 tries to push it to B's socket — but B's socket lives in Worker 2's memory, not Worker 1's. So the message gets saved to the DB, but real-time delivery to B fails.
Also, workers are standalone, so they can't even talk to each other to ask "do you have this user with you?"
A TCP socket lives inside one process.

STICKY Session
Imagine a user lands on Worker A and creates a socket connection. Details regarding the session are stored in Worker A's memory. Somehow, on the next request, the user is shifted to Worker B. Now the user tries to continue the conversation. The worker checks if this session exists or not, but there is no record of it in Worker B (that detail lives in Worker A). So the interaction fails.

To make it easier to picture, here are two ways to think about it:

Analogy 1 (hotel front desk) — You check into Hotel A. The front desk writes your name against Room 204. Later, you walk into Hotel B and ask for your room key. Hotel B has no idea who you are, because your check-in details only exist at Hotel A's front desk.

Analogy 2 (locker at a station) — You drop your bag at locker #5 in Station A and get a ticket. Later, you go to Station B and try to use the same ticket. Station B has no locker matching that ticket, because the bag is sitting back in Station A.

To mitigate this issue, we need Sticky Sessions. It ensures that a user stays on a single worker only — pinning all of one client's requests to the same worker.

One more thing worth knowing — Socket.IO's connection handshake itself is made of multiple HTTP requests (long-polling fallback) before it upgrades to WebSocket. Without stickiness, those handshake requests can scatter across different workers, and the connection never even establishes. So sticky sessions are needed not just after the user is connected, but during the initial connection itself.

REDIS ADAPTER for SOCKET
Even with stickiness, workers still can't communicate with each other. So User A on Worker 1 has no way to push a message to User B sitting on Worker 2. This is a major issue in applications using sockets or real-time communication. To solve this, we have adapters — one of them is the Redis adapter for Socket.IO. It acts as a coordination layer on pub/sub. With this in place, when Worker 1 emits a message, the adapter publishes that emit to a shared bus (Redis). Every worker is subscribed to this bus, and the worker that actually owns B's socket picks it up and delivers the message locally. Now the application will work just like an application running on a single instance.

STICKY + ADAPTER
The two solve different problems, and you actually need both together.

Sticky sessions make sure a user's requests always land on the same worker, so the connection (and the handshake) never breaks mid-way.
The Redis adapter makes sure that when a worker needs to push a message to a user sitting on a different worker, the message can still reach them through the shared pub/sub bus.

Sticky alone — your user stays connected, but messages between users on different workers still don't reach. Adapter alone — workers can broadcast across each other, but the initial connection itself keeps breaking. Together — your clustered app behaves like a single instance from the user's perspective.

TL;DR
Node is single-threaded. Clustering spawns one worker per core. REST scales for free because the DB is shared. Sockets don't — connections live in one worker's RAM. Fix with sticky sessions (so handshakes complete) plus a pub/sub adapter (so workers can deliver each other's messages).

So this sums up basic clustering in a node.js application.
Thanks for reading.

DOCKER — A MUST KNOW TOOL FOR EVERY DEVELOPERs

Blackwatch — Tue, 14 Apr 2026 15:34:47 +0000

Ever came across the meme:
“But it works on my computer”

If you know docker, then you will understand its meaning, a single line but a very big issue is hidden beneath that meme. So lets dive deep into it and lets understand what docker is and why we need it.

Problem

Imagine you joined a team as a frontend developer, and you were tasked to run the code on your local machine. You followed the instructions. You installed Node in the system, then installed Git. Now you cloned the project and installed all of the dependencies and you hit npm run dev

It took its time and you saw errors in console.
Error → Incompatible Node version

You connected with your team, they helped you install the correct versions of all the services and environment. Now you ran the code again, and again you ran into an error. Now the issue was the system. You are using macOS while the team is working on Windows—different architecture, different tools.

Now you solved this issue and you need to deploy the application on cloud. There also you will have to add all of these configurations to make it up and running. Pretty hectic.

Team has to do this every time a new member joins.
Here comes Docker for our rescue.

DOCKER

There is a concept of containers in Docker. It’s like an isolated environment which can be configured as per the requirements—from OS-level dependencies to tools needed to run the app.

Once it's set up, it can be shared among other team members and they can run it easily. Now there will be no issue running the application, because containers have their own environment. Even if team members have Windows, Linux or macOS*—it will still run*.

To do so, first we need to install:

Docker CLI (command line interface)
Docker Desktop (GUI)

You can download Docker from the official site and follow the instructions to install and run it.

Docker Components

Docker has two parts, one is the docker Engine (daemon) and second is docker desktop.

1. Docker Engine (Daemon)
It is the main crux of docker, it runs in background doing everything, from managing images, containers to run them, managing their lifecycle

2. Docker Desktop
It a GUI(graphical user interface) which gives ease to user to use and run docker without going into too much technicality.

Verify Installation

docker -v

If installed correctly, you’ll see something like:
Docker version 29.x.x

CONTAINERS and IMAGES

Whole Docker system revolves around these two.

1. Containers
These are the environment, which is required to run an image and each container is separated for other containers. Means container 1 don’t have access to the files/data of container 2 and vice versa.

A container is basically a running instance of an image.

2. Images
You can think of it as a blueprint which already has everything installed (like node, dependencies, etc). Contains everything needed to run an app

CUSTOM IMAGES
We can also create custom images and push them on docker hub, which is a collection of images for docker, just like github where other users or team members can download these images and run it in their systems(docker)

Imagine you have a MacBook, which is running macOS inside it. Now the containers act like MacBook and images acts like macOS. Images running inside container.

Analogy

Image = blueprint
Container = running application

Basic Commands

Good for the basics, now lets play around with docker commands

1. Run container

docker run -it image_name

Creates + starts a container from an image
Opens interactive terminal
Container name will be random
Pulls image from docker hub if not available locally

2. List containers

docker container ls
OR
docker container ls -a

list downs all running containers -a List downs all of the containers, even the stopped ones

3. Start/Stop

docker start container_name
AND
docker stop container_name

4. Execute command inside container

docker exec container_name ls

It runs the ls command inside a running Docker container and exits after running the command

docker exec -it container_name bash

_Opens interactive shell inside container, now you are inside the container _

exec = execute
-it = interactive

Exit

Ctrl + D

5. List images

docker images 
OR 
docker image ls

PORT MAPPING

You might be thinking that the containers are isolated in nature, they don’t interact with other container or outside world(system) then how can we run and test projects on our system. Take an example, you pulled a node application and it is running in the container

docker run -it imageName

Now you might open a tab localhost:9000. But you will see nothing there, why cause that application is running inside the container, and our system doesn’t know anything about it.

In this situations, we need port mapping/need to expose the ports to the system.

How we do it, using -p tag followed by system port : container port

docker run -it -p 9000:9000 image_name

here we mapped the port 9000 of container to our system’s 9000 port. Now you can check localhost:9000 Application will be up and running.

We can set it to any port and we can map multiple ports as per the requirement

docker run -it -p 4584:9000 -p 2300:3000 image_name

ENVIRONMENT VARIABLES

Now you may ask, we create environment variables in our projects, we store secret keys in it and other important data, which only we have. So how can we set these in the container.

It's a genuine question and the solution is very easy, all we need to do is to use -e followed by key=value

docker run -it -p 4584:9000 -e jwtSecret=secretisthis -e production=false image_name

This is all the basics you need to understand what docker is and how to work with it. Now lets move one step further and lets containerize a very simple node server.

You can create your very own node server or you may use this tutorial app for this tutorial.

Your simple server is ready, now we have to containerize, make an image of it so others can use it.

To do so, we need a Dockerfile where we will be writing down all of our configurations.
Note – the name should be Dockerfile without any extension

DOCKERFILE

FROM ubuntu:22.04 
# base image, it can be node, redis etc

WORKDIR /app
# Set working directory

#Install Node.js
RUN apt-get update && \
apt-get install -y curl ca-certificates && \
curl -fsSL https://deb.nodesource.com/setup_18.x | bash - && \
apt-get install -y nodejs && \
apt-get clean && \
rm -rf /var/lib/apt/lists/*


#Copy dependency files first (for caching)
COPY package.json package-lock.json ./

#Install dependencies
RUN npm install

#Copy rest of the app
COPY . .

#Tells to run these files whenever someone runs the image
ENTRYPOINT ["node", "main.js"]

Build Image
Now the configuration is complete, all we need do to is to make an image. For that the command is

docker build -t docker-tutorial .

Note - . as path cause I am in the same directory as of the Dockerfile

It will take some time, once its done you will see your image in your docker desktop app or you can use the command in terminal too.

Run Container
Now you can run it and test if its working or not.

docker run -it -e PORT=4567 -p 8000:4567 docker-tutorial

here I am passing environment variable PORT and I am mapping that port to system’s port 8000. Now I can see my application running on localhost:8000.

CACHING
Each line in Dockerfile = layer

If one layer changes → all layers after it rebuilds

That’s why:

COPY package.json ...
RUN npm install
COPY . .

is important for performance.

PUSH TO DOCKER HUB

Now you want to share your custom image with your teammates or with the world. To do so, first you need to create an account on docker hub

There you need to create a repository, once its created, then you will see a command like this

docker push your_user_name/docker-tutorial:tagname

This is the command that we will be using to push our image to the docker hub, but before that we have to create that image as per the notations.

Create the image, with name your_user_name/repository_name

In our case it will be

docker build -t  your_user_name/docker-tutorial_ .

Once image is created, you can check it on docker desktop or using commands in cli

Now we need to run our push command.

docker push username/docker-tutorial:tagname

All done, check your repository on docker hub, you will see your docker image there. Now you can share this image with others and they can run it directly. No environment setup, no package matching needed. Just run it. That’s it.

DOCKER COMPOSE

Lets move to more advance part
Imagine you are working on a very big project, which needs nodejs, postgresql, redis, mailhog etc. Now you can either go and run each image one by one, or we can use docker compose. It’s a file where we configure all of the services (images), and with a single command all of them will start/stop. No manual efforts, just a single command to spin up the application.

To do so, we need to create a docker-compose.yml file, where we will be writing all of our configurations

version: "3.8"

#services is where we will add all of the images, that we need to run
services:
  postgres:
    image: postgres
    ports:
      - "5432:5432"
    environment:
      POSTGRES_USER: postgres
      POSTGRES_DB: review
      POSTGRES_PASSWORD: password

  redis:
    image: redis
    ports:
      - "6379:6379"

Run everything

docker compose up

Stop everything

docker compose down

This pretty much sums up what Docker is, why we need it, and its importance in today’s development world. Hope you learned something useful from this.

Till next time,
Peace out

How I Built TERMINAL47: Anonymous Real-Time Chat with Live Translation (Next.js + Socket.io + TypeScript + Express)

Blackwatch — Mon, 23 Feb 2026 15:59:48 +0000

Zero-friction chat app—no signup, link-only access, anonymous "Agent-X" names, set duration for room, auto room dispose once time is over, no data is saved/stored, pure anonymity, live language switching (history bulk-translates + new messages stream). Hacker terminal UI. V1 complete github

Live chat with users sidebar, countdown timer, translation status.

Hey devs!, I wanted to level up my skills, so I combined Socket.io + real-time multilingual chat + cyberpunk UI. Meet TERMINAL47.

The Flow: Share link → Join as anonymous agent → Chat → Switch English→Japanese mid-convo → All past messages instantly translate → New messages are translated in real time →Timer expires → Room erased forever.

🛠️ Tech Stack (Production Architecture)

Frontend: Next.js 16 + TypeScript 
Backend: Express + Socket.io + Lingo.dev SDK
State: useState (local) + localStorage (userName)
Storage: None (pure ephemeral)
Deployment: Local dev → GitHub

Step 1: Backend Setup (index.js)
Clean Express + Socket.io server with dedicated translation endpoints:

// index.js
import express from "express";
import { createServer } from "http";
import { Server } from "socket.io";
import socketEvent from "./socket/events.js"; // Room logic here
import languageTranslationBulk from "./utils/translationBulk.js";
import languageTranslationSingle from "./utils/translationSingle.js";

const app = express();
const server = createServer(app);
const io = new Server(server, { cors: { origin: process.env.CLIENT_URL }});

app.use(cors());
app.use(express.json());


app.post("/auth/translation/bulk", async (req, res) => {
  const { messages, currentLanguage, translateTo } = req.body;
  const languageTranslationFunction = await languageTranslationBulk(
    messages, currentLanguage, translateTo
  );
  res.json({ success: true, data: languageTranslationFunction });
});

app.post("/auth/translation/chunk", async (req, res) => {
  const { message, currentLanguage, translateTo } = req.body;
  const languageTranslationFunction = await languageTranslationSingle(
    message, currentLanguage, translateTo
  );
  res.json({ success: true, data: languageTranslationFunction });
});

socketEvent(io); // Room management

Step 2: Lingo.dev Integration
Bulk translation (history on language switch):

// utils/translationBulk.js -
import { LingoDotDevEngine } from "lingo.dev/sdk";

const languageTranslationBulk = async (messages, currentLanguage, translateTo) => {
  const lingoDotDev = new LingoDotDevEngine({ apiKey: process.env.LINGO_DEV_API_KEY });
  const userMessages = messages.filter((msg) => msg.text != "");

  const translated = await lingoDotDev.localizeText(userMessages, {
    sourceLocale: currentLanguage,
    targetLocale: translateTo,
  });
  return translated;
};

Step 3: Frontend Hook (useChat.ts)

// hooks/useChat.ts
export const useChat = () => {
  const [socket, setSocket] = useState<Socket | null>(null);
  const [roomStatus, setRoomStatus] = useState<boolean | null>(null);
  const [expiresAt, setExpiresAt] = useState<number | null>(null);

  const joinRoom = useCallback((roomId: string, userName: string) => {
    socket?.emit("join_room", { roomId, userName }, (result: any) => {
      if (result.success && result.room) {
        const expiry = Date.now() + result.room.timeRemaining;
        setExpiresAt(expiry);
      }
    });
  }, [socket]);

  const sendMessage = useCallback((roomId: string, message: string) => {
    socket?.emit("send_message", { roomId, message });
  }, [socket]);

  return { socket, joinRoom, sendMessage, roomStatus, expiresAt };
};

Step 4: 🔥 Live Translation Magic (Chat.tsx)
Hero feature—language switch + bulk/single translation:

useEffect(() => {
  if (!allMessages.length || language === lastLanguage) return;

  setIsTranslating(true);
  const translateChat = async () => {
    const response = await fetch(`${process.env.NEXT_PUBLIC_BACKEND_URL}/auth/translation/bulk`, {
      method: "POST",
      body: JSON.stringify({
        messages: allMessages,
        currentLanguage: lastLanguage,
        translateTo: language,
      }),
    });
    const data = await response.json();
    setAllMessages(data.data); // All history translated!
  };
  translateChat();
}, [language]);

Switch language → History bulk-translates + new messages auto-translate.

Step 5: SideNavBar (Users + Timer)

// SideNavBar.tsx - Key features
const SideNavBar = ({ userCount, expiresAt, language, setLanguage, isTranslating }) => {
  const [formattedTime, setFormattedTime] = useState("00:00");

  useEffect(() => {
    if (!expiresAt) return;
    const tick = () => {
      const remainingMs = expiresAt - Date.now();
      const totalSeconds = Math.max(0, Math.floor(remainingMs / 1000));
      const minutes = Math.floor(totalSeconds / 60);
      setFormattedTime(`${minutes.toString().padStart(2, '0')}:${(totalSeconds % 60).toString().padStart(2, '0')}`);
    };
    tick();
    const interval = setInterval(tick, 1000);
    return () => clearInterval(interval);
  }, [expiresAt]);

  return (
    <aside className="w-12 md:w-64 bg-secondaryBackground">
      <div>USERS- {userCount}</div>
      <LanguageSelection language={language} setLanguage={setLanguage} />
      <div className="timer">{formattedTime}</div> {/* Red border when <60s */}
    </aside>
  );
};

🚀 V1 Complete ✅
✅ Real-time chat (Socket.io)
✅ User presence + system messages
✅ Live translation (bulk + streaming)
✅ Room expiry countdown
✅ Hacker terminal UI
✅ Anonymous access (no auth)
✅ TypeScript everywhere

Next: Typing indicators with Redis V2? Clone the repo and try language switching—feels like magic! 🪄
Github

QUICK SQL REVISION

Blackwatch — Sun, 04 Jan 2026 14:33:01 +0000

While revising SQL, I realized that I keep making the same notes again and again. So I decided to document everything in one place for quick reference.

As I was writing, I thought—why not share it as an article? It might help others who are learning SQL or revising for interviews.

This article covers the core SQL concepts and is intended as a quick revision guide as well as an easy starting point for beginners.

SQL

What is SQL?
SQL stands for Structured Query Language and is the standard language used to interact with relational databases. It allows us to:

Create database structures like tables, views, and indexes.
Perform CRUD operations (Create, Read, Update, Delete) on the data stored in those tables.
Define permissions and control access to the data.
CRUD expands to:
C – Create
R – Read
U – Update
D – Delete

What is a database?
A database is a structured collection of data stored in a digital system so that it can be efficiently accessed, managed, and updated. It acts as the backbone of most applications because it persists user and system data; without it, most apps would lose their state and real-world usefulness.
Databases are broadly categorized into:

Relational databases
Non-relational (NoSQL) databases

Relational databases
In relational databases, data is stored in tables (rows and columns) with a predefined schema. This structure:

Makes it easier and faster to query data using relationships (joins) between tables.
Requires designing the schema up front, so a good understanding of the data model is needed before implementation.
Examples:
MySQL
PostgreSQL
SQL Server
Oracle

*Relational databases use SQL as their primary query language

Non-relational databases
Non-relational (NoSQL) databases do not rely on fixed tables and schemas like relational databases. Data can be stored as documents, key–value pairs, wide-column stores, or graphs. This:

Makes it easier and faster to get started because the schema can be more flexible or even schema-less.
Can become harder to reason about as the data model grows if there is no consistent structure.
Can scale very well horizontally for certain workloads, though query patterns and consistency guarantee differ from relational systems.
Examples:
MongoDB (document-based)
Redis (key–value)
Cassandra (wide-column)

Data Types
Before moving forward, it is important to understand the concept of data types in SQL. Like most programming languages, when creating a table, we must specify the type of each column so the database knows what kind of data it will store and how to validate it.
Data types help:

Enforce that data is stored in the correct format (numbers, text, dates, etc.).
Optimize storage and performance by choosing appropriate sizes and representations.

Most Common Data Types
SQL offers Different Data Types but here we will discuss about most common data types.

1. CHAR

CHAR(n) is a fixed-length character type used to store strings with a maximum length of n characters, for example CHAR (21).
The database reserves space for exactly n characters for each value; if the string is shorter, it may be padded with spaces internally.
If you try to insert a string longer than n, it will either be truncated or cause an error, depending on the database and settings. Use cases: values with fixed length such as country codes, status codes, or fixed-format identifiers.

2. VARCHAR

VARCHAR(n) is a variable-length character type used to store strings up to n characters.
Unlike CHAR, it only uses as much storage as needed for the actual string plus a small overhead, not the full declared length.
If a value exceeds the specified maximum length, the database will usually throw an error or truncate based on configuration. Use cases: general text fields like names, emails, addresses, titles, etc.

3. INT

INT is used to store whole numbers (integers).
Exact range depends on the database system and whether it is signed or unsigned, but it typically supports a large range of positive and negative values suitable for IDs, counts, and similar fields. Use cases: IDs, counts, quantities, ages, and other whole-number values

4. TINYINT

TINYINT is a smaller integer type with a limited range.
In MySQL, for example, TINYINT has a range of -128 to 127 when signed, and 0 to 255 when unsigned.
It is useful when you know values will always remain within a small range, which can save space. Use cases: small flags, status codes, or compact numeric values.

5. FLOAT

FLOAT is a floating-point data type used to store approximate decimal numbers.
It is called single-precision because it stores numbers using fewer bits, which means less precision compared to DOUBLE.
In most databases, FLOAT can accurately represent about 6–7 significant digits.
Because values are stored in binary form, some decimal numbers cannot be represented exactly, which may result in small rounding errors.
Due to this approximation, FLOAT should not be used for values where exact precision is required (such as money). Use cases: Measurements, percentages, averages, sensor data, or scientific values where minor rounding differences are acceptable.

6. DOUBLE

DOUBLE (or DOUBLE PRECISION) is a floating-point data type used to store approximate decimal numbers with higher precision than FLOAT.
It uses more bits to store each value, allowing for about 15–16 significant digits of precision in most systems.
DOUBLE supports a wider range and greater accuracy than FLOAT, making it suitable for more complex calculations.
Like FLOAT, it still stores values approximately, so exact precision is not guaranteed. Use Cases: Scientific computations, complex calculations, analytics, and scenarios where higher precision is needed but exact decimal accuracy is not mandatory.

7. Boolean

Conceptually, a Boolean represents two logical values: true and false.
Many SQL dialects have a BOOLEAN or BOOL type; however, the actual storage may be implemented internally as a small integer (for example, TINYINT(1) in MySQL).
In systems that represent Boolean as integers, the common convention is 0 for false and 1 for true. Use cases: flags like is_active, is_deleted, is_admin, etc.

8. DECIMAL / NUMERIC

DECIMAL (also called NUMERIC in many SQL dialects) is used to store exact decimal numbers.
Unlike FLOAT and DOUBLE, DECIMAL stores values in base-10, which means decimal numbers are stored exactly as written, without rounding errors.
DECIMAL (p, s) defines precision (total digits) and scale (digits after decimal).

Rule of thumb:
Use FLOAT/DOUBLE for measurements and calculations, but DECIMAL for money and financial data.

Use cases: Monetary values, prices, salaries, financial calculations, totals, taxes, and any scenario where precision must be exact.

Signed and unsigned integers
Sometimes you know a column will never store negative values, such as IDs, counts, or quantities.
• Signed integers can store both negative and positive values (for TINYINT in MySQL: -128 to 127).
• Unsigned integers only store non-negative values but shift the range upward (for TINYINT in MySQL: 0 to 255).
Example:

_id TINYINT UNSIGNED

Here, _id can only store values from 0 to 255, which is enough for a small set of teacher IDs and saves space compared to a larger integer type.

Types of Commands in SQL
We know that SQL is a language which is used to interact with database, there are various types of commands with each having its own function, now these commands can be classified into 5 types, and these are –

1. DDL (Data Defining Language)
Purpose: Define and manage database structure (tables, schemas).
Examples:

CREATE - create tables/databases
ALTER - modify existing tables
DROP - delete tables/databases
TRUNCATE - delete all data (keep structure)
RENAME - rename objects

2. DQL (Data Query Language)
This is used to retrieve data from tables. We can apply conditions too, to get specific data.
Examples:

SELECT - fetch data with conditions, joins, etc.

3. DML (Data Manipulation Language)
This is used to manipulate the data present/stored inside the table. We can CRUD operations;
Examples:

INSERT - add new data
UPDATE - modify existing data
DELETE - remove data

4. DCL (Data Control Language)
This is used to grant and revoke permissions to users. As the data grows, we may also add sensitive data in it or there may be data which isn’t needed by one user. So, we can limit what the user is allowed to access to maintain security.
Examples:

GRANT - give permissions
REVOKE - remove permissions

5. TCL (Transaction Control Language)
One of the most important concepts, although it is used massively in applications. Where it ensures that whole operation is done as per the instructions other wise revert back to the last check point
Examples:

BEGIN/COMMIT - save changes
ROLLBACK - undo changes
SAVEPOINT - partial rollback points

Basic Command (Create table)
As we know that SQL is a language and everything is done using commands. So here is the most basic command. Which will help us to understand other concepts.

List all Databases

SHOW DATABASES;

Use a specific database

USE database_name

List all tables in current DB

SHOW TABLES;

View table structure

DESC table_name

DESC students;

Create table (DDL)

CREATE TABLE table_name(
   column_1 datatype constraint,
   column_2 datatype constraint,
   column_3 datatype constraint, 
);

Ex-

CREATE TABLE student(
   Id INT PRIMARY KEY AUTO_INCREMENT,
   first_name VARCHAR(50) NOT NULL,
   last_name VARCHAR(50) NOT NULL,
   phone VARCHAR(15),
   age INT NOT NULL
);

NOTE-
Here PRIMARY KEY is a key
AUTO_INCREMENT, NOT NULL are constraints
We will learn about these in future.

DELETE DATABASE/TABLE

DROP DATABASE database_name;

DROP TABLE table_name;

KEYS
PRIMARY KEY (always unique)
A column (or set of columns) in a table that uniquely identifies each row (a unique id)
Only one Primary key can be there in a table and it can’t be null.

Ex-

CREATE TABLE students(
   id INT PRIMARY KEY,
   ……
);

FOREIGN KEY
It’s always a good idea to divide data into small tables, rather than keeping everything inside a single table which is a monolith architecture. Now as we divide the tables, we need to establish some sort of relation in between them which allows us to get the data. FOREIGN key in a table refers to the PRIMARY key of another table and helps in establishing that link between tables.
FOREIGN KEY References PRIMARY KEY of another table
A table can have multiple FKs.
Foreign keys may contain null or duplicate values.

Parent table = table with PRIMARY KEY
Child table = table with FOREIGN KEY

Example

A teacher table is in relation with department table.

CREATE TABLE dept(
   id INT PRIMARY KEY,
   name VARCHAR(50)
);  

CREATE TABLE teacher(
   id INT PRIMARY KEY,
   name VARCHAR(50),
   dept_id INT,

   FOREIGN KEY (dept_id) REFERENCES dept(id);
);

Here dept is the Parent table while teacher is the Child table (using Foreign Key) and dept_id in teacher table is the FOREIGN KEY, which establishes relation between these two tables.

CASCADE in FOREIGN key
FOREIGN key is used to set up relation between tables. Now there may be a need of change in both tables if anything is changed in parent table, for that we use CASCADING

So, any change(s) in parent table is automatically reflected in children table too.

ON UPDATE CASCADE → Parent ID changes → Child FK updates automatically
ON DELETE CASCADE → Parent row deleted → Child rows deleted automatically

CREATE TABLE teachers(
   Id INT PRIMARY KEY AUTO_INCREMENT,
   Name VARCHAR(50),
   dept_id INT,

   FOREIGN KEY (dept_id) REFERENCES dept(id)

   ON UPDATE CASCADE
   ON DELETE CASCADE
);

CONSTRAINTS
Now let’s talk about CONSTRAINTS, while creating a table we can specify some rules for the columns in the table. Like the values can never be null, we can specify the length, allow duplicate values or not. All these rules are applied using CONSTRAINTS.

Some Commonly used CONSTRAINTS
1. NOT NULL – This is used to specify that the column can’t be null. There should be a value in it all the time.
2. UNIQUE – In case we want to have unique values in a column, then we use this.
3. DEFAULT – This is used to set a default value, in case no value is provided, then the set default value is used.
4. CHECK - This is used to check or set the permissible value in the column

Ex.

CREATE TABLE student (
   _id INT PRIMARY KEY,
   first_name VARCHAR (50) NOT NULL,
   last_name VARCHAR (50) NOT NULL,
   phone VARCHAR (15) NOT NULL UNIQUE,
   age INT CHECK (age>=18),
   city DEFAULT 'ABCD'
);

SELECT statement
Till now we learned about databases, their types, data types, types of commands, how to create a table, concept of keys and constraints. Now we will dive into the ocean of commands, how we can actually use the commands and play with data and to do so, first and foremost thing we have is the SELECT statement, it is used to retrieve data from the table and return it.

SELECT col1, col2, col3 FROM table_name;

SELECT * FROM student;

Here the above command will return whole table as the result, * means all.

Targeting specify column in a table.

SELECT id, name, city FROM students;

Above command will return a table with only id, name and city column.

Column aliases (AS):
In case we want to change “name” to “first_name” in the resultant table, then we can use AS command to do so.

SELECT id, name AS first_name, city FROM students;

In the resultant table, now the columns will be id, first_name, city. But this won’t affect the actual table in anyways.

CONDITIONS – WHERE clause
What if we need specific data from the table, which satisfies certain conditions. To do so, we use WHERE clause with the SELECT statement. WHERE clause allows us to set conditions.

SELECT col1, col2, col3, col4…   FROM table_name WHERE condition;

WHERE clause doesn’t work alone, conditions are set with the help of OPERATORS.

OPERATORS
OPERATORS are the backbone of SQL, as they allow us to actually set the conditions as per our requirements.
There are various OPERATORS to choose from, and these are the most commonly and important to know OPERATORS.

1. Arithmetic OPERATORS: *, -, +, /, %

SELECT name, age/2 AS age_divided_by_two FROM students;

SELECT *, age-4 as MINOR FROM students WHERE age-4<18;

2. Comparison OPERATORS: =, !=, >, >=, <, <=
These are used to do comparison
*Note: != means not equal to

SELECT * FROM students WHERE city='New York' AND age>21;

3. BITWISE OPERATORS: & (Bitwise AND), | (Bitwise OR)

4. Logical OPERATORS: AND, OR, NOT, IN, BETWEEN, ALL, LIKE.
These are logical in nature

AND operator: This checks if both (right and left) conditions are true, then only it satisfies the conditions.

SELECT * from students
WHERE name='John' AND age>26;

OR operator: Similar to AND operator but this checks if either of the conditions is true.

SELECT * FROM students
WHERE name='Wick' OR age>50;

BETWEEN operator: Used to set a range for the result.

SELECT * FROM students
WHERE marks BETWEEN 80 AND 92;

IN operator: It matches any value specified inside it.

SELECT * FROM students
WHERE city IN ('New York', 'Moscow', 'New Delhi')

This will only return the rows, where the city is New York, Moscow, or New Delhi only.

NOT: To negate the given condition

SELECT * FROM students
WHERE city NOT IN ('New York', 'Moscow', 'New Delhi')

This will return all the rows except the rows where the city is New York, Moscow, or New Delhi

LIMIT: Used to set the limit of returned rows of the table.

SELECT * FROM students LIMIT 5;

Now, the result will contain only 5 rows at a time, even if it contains 100 rows. It will only be returning 5 rows at a time.

OFFSET: This one is used to skip certain values and start after them.

LIMIT and OFFSET are used together and these two OPERATORS make pagination in web page possible.

ORDER BY: This gives us the facility to sort the result as per our choice. Either Descending or Ascending.

SELECT * FROM table_name 
ORDER BY col_name ASC

ASC= Ascending
DESC= Descending

SELECT * FROM students
WHERE city NOT IN ('Rome', 'Tokyo') 
ORDER BY name DESC
LIMIT 2 OFFSET 2;

AGGREGATE FUNCTIONS
These are prebuilt functions/methods which helps us by easing our work, these returns single value as a result.

COUNT() - Counts the number of entries
MAX() - Maximum value in column
MIN() - Minimum value in column
SUM() - Total sum of values
AVG() - Average of values.

Find the max age-

SELECT MAX(age) as MaxAge FROM students;

     OR

SELECT age FROM students ORDER BY age DESC LIMIT 1;

GROUP BY clause
This is used to group rows that have same values into summary rows.
Generally used with some aggregate function. Both of these goes by hand in hand.

SELECT SPID, SUM(amount) 
FROM sales 
GROUP BY SPID 
ORDER BY SPID ASC;

HAVING clause
Similar to WHERE clause but used when we want to apply condition after grouping.
It was introduced to address the limitations of WHERE clause, which cannot be used with aggregate functions.

SELECT city , COUNT(name)
FROM student
GROUP BY city 
HAVING max(marks)>90;

GENERAL SEQUENCE/ORDER of writing query

SELECT columns(s)
FROM   table_Name
WHERE condition
GROUP BY column(s)
HAVING condition
ORDER BY column(s) ASC/DESC

SELECT city
FROM   students
WHERE grade='A'
GROUP BY city
HAVING MAX(marks) > 90
ORDER BY city ASC/DESC

TABLE Related Queries
1. Create Table

CREATE TABLE table_name(
   column_1  datatype constraint,
   column_2  datatype constraint,
   column_3  datatype constraint, 
);

Ex-

CREATE TABLE student(
   Id INT PRIMARY KEY AUTO_INCREMENT,
   first_name VARCHAR(50) NOT NULL,
   last_name VARCHAR(50) NOT NULL,
   phone VARCHAR(15),
   age INT NOT NULL 
);

2. Insert data

INSERT INTO tablename(col1,col2,col3,….) 
VALUES(val1,val2,val3,….);

INSERT INTO students(id,first_name,last_name,phone,age)
VALUES(1, 'John', 'Wick', '7878787878', 35);

In case you know the order then you may omit the column names

INSERT INTO students
VALUES(1, 'John', 'Wick', '7878787878', 35);

Notice that we have used AUTO_INCREMENT for id. Which means that the value will increase by its own. To do that, we have to use the columns name and omit the AUTO_INCREMENT column.

INSERT INTO students (first_name, last_name, phone, age) 
VALUES ('John', 'Wick', '7878787878', 35)

Here, id will be populated on its own.

Insert more than one value/row in table

INSERT INTO students(first_name, last_name, phone, age)
VALUES ('John','Wick', '7878787878', 35),
   ('Super', 'Man', '8456985',20),
   ('Bat', 'Man', '2234234',45),
   ('Iron', 'Man', '23584839', 55),
   ('Captain', 'America', '284738473/, 50);

3. Update table

UPDATE table_name 
SET col1=val1 
WHERE condition

UPDATE student 
SET age=44 
WHERE first_name='SUPER';

4. Delete data

DELETE FROM table_name
WHERE condition;

DELETE FROM students 
WHERE first_name= 'Delete';

5. ALTER TABLE

ADD column

ALTER TABLE table_name
ADD COLUMN col_name datatype constraint;

ALTER TABLE students
ADD COLUMN grades VARCHAR(2) NOT NULL;

DROP/DELETE Column

ALTER TABLE table_name
DROP COLUMN column_name;

ALTER TABLE students
DROP COLUMN grades;

RENAME table

ALTER TABLE table_name
RENAME TO newtable_name;

ALTER TABLE students
RENAME TO newStudents;

CHANGE column

ALTER TABLE table_name
CHANGE COLUMN old_name new_name new_datatype new_constraint;

ALTER TABLE students 
CHANGE COLUMN last_name lastName VARCHAR(20) NOT NULL;

MODIFY column (modify datatype/constraint)

ALTER TABLE table_name
MODIFY col_name new_datatype new_constraint;

ALTER TABLE students
MODIFY phone VARCHAR(15) UNIQUE;

DELETE TABLE data (only table data, not whole table)

TRUNCATE table_name;

TRUNCATE students;

JOINS
One of the most important topics, these are used to combine rows from two or more tables, based on a related column between them.

Types

Inner Join
Outer Join

Left Join
Right Join
Full Join

1. INNER JOIN
Returns records that have matching values in both tables (only mutual data is returned)

SELECT column(s) FROM table_A 
INNER JOIN table_b 
ON tableA.col_name = tableB.col_name;

SELECT * FROM students
INNER JOIN course
ON student.student_id = course.student_id;

*This will return only the data which is present in both tables

OUTER JOINS
1. LEFT Join

Returns all records from left table and matched records from the right table.

SELECT column(s)
FROM tableA
LEFT JOIN tableB
ON tableA.col_name = tableb.col_name;

2. RIGHT Join
Same as LEFT join, only side changes. This return all records from right table and matched records from left table.

SELECT column(s) 
FROM tableA
RIGHT JOIN tableB
ON tableA.col_name = tableb.col_name;

3. FULL Join
Returns all records even if there is no relation.
By default, MySQL doesn't support FULL JOIN so we do it through another method and with using UNION.

UNION
Helps in combining data and returns unique values only.

FULL JOIN = LEFT JOIN _UNION _RIGHT JOIN

SELECT * FROM tableA as A
LEFT JOIN tableB as B
ON A.column = B.column

UNION

SELECT * FROM tableA as A
RIGHT JOIN tableB as B
ON a.column = b.column;

??Write SQL command to display the left exclusive join: -

SELECT * FROM tableA as A
LEFT JOIN tableB as B
ON A.col_name = b.col_name
WHERE b.id IS NULL;

*Similar for RIGHT exclusive Join.

SELF JOIN
A regular join but the table is joined with itself

SELECT column(s)
FROM table as A
JOIN table as B
ON A.col_name = B.col_name;

UNION
Used to combine the result-set of two or more SELECT statements.
Gives unique records.
*Columns must have similar data types.

SELECT column(s) FROM tableA
UNION
SELECT column(s) FROM tableB;

*We also have UNION all, this allows duplicates on top of UNION's data

SUBQUERY
Subquery or inner query or a nested query is a query within another SQL query. This allows us to do complex operations which isn't or would be hard to do otherwise.

SELECT column(s)
FROM table_name
WHERE col_name operator/condition(subquery)

SELECT name, marks
FROM student
WHERE marks > (SELECT AVG (marks) FROM student);

MySQL Views
It's a virtual table created from an actual/real table.
Imagine a student table with lots of columns. Now a teacher only needs students roll number, name, marks. Other data isn't needed to the teacher.

So, a view will be created from the student table which will contain only these columns.

Although it's a virtual table but it will act just like a real table, operations, select command etc.

CREATE VIEW

CREATE VIEW view_name AS 
SELECT column(s) 
FROM table_name;

CREATE VIEW view1 AS 
SELECT rollno, name, marks 
FROM student


SELECT * FROM view1;

DROP VIEW

DROP VIEW view_name;

DROP VIEW view1;

Wanna know the working of Video calling apps (zoom, google meet, microsoft teams) how they work, here is a quick article on it. What goes behind a video call, how things work, its architecture. Feel free to give it a try😁

Blackwatch — Thu, 17 Jul 2025 05:51:38 +0000

Blackwatch

Jul 16 '25

WebRTC, the Brain Behind Your Virtual Video Calls

#webdev #webrtc #programming #beginners

6 min read

WebRTC, the Brain Behind Your Virtual Video Calls

Blackwatch — Wed, 16 Jul 2025 14:38:39 +0000

Ever wondered what goes behind apps like Google Meet or Zoom? How do they make it so easy for us to communicate through video, even when we're sitting on opposite sides of the planet?

Yeah, I came across this while building an app for myself. That’s when I learned more about WebRTC—how it works, what goes on behind the scenes, what its architecture looks like, its drawbacks, and how to overcome them. In this article, I’ll give you a brief intro to WebRTC and its working principles. So stay tuned to dive deep into the world of video calling.

WebRTC—What Is This?

It’s a protocol used to connect users directly so they can communicate, share files, stream video, and more.

But aren’t there other protocols for that? What’s so special about this one?

Right, there are many protocols. But WebRTC shines because of its ease of use, and the fact that you don’t need a dedicated server to monitor or relay the entire communication. It’s based on the UDP protocol.

Yes, you heard it right—WebRTC doesn’t need a third-party or cloud-based server for actual media transfer. It establishes a direct peer-to-peer connection between users, which also makes it faster.

So Why Don’t We Use This Everywhere?

You might have the same question in your head. The reason is packet loss.

WebRTC is based on UDP, which is fast, but not reliable—it doesn’t guarantee that all data packets will reach the destination. That’s fine for things like Zoom meetings or online games, where a small data loss (a freeze or glitch) doesn’t affect much.

But for messaging apps, we can’t afford to lose even a single packet—missing words or characters can change the entire meaning of a message. So for these cases, we use TCP, which ensures reliable and ordered delivery of data.

In short:

Use UDP/WebRTC for real-time media (video/audio).
Use TCP when all data must be received correctly (text, files).

How It Works – Architecture

Before diving in, let’s imagine a situation:
You want to call your friend, family member, boss (to ask for leave 😁), or your wife (to plan a day out). To do that, you need their phone number. Only then can you call them.

Similarly, in WebRTC, you first need to know the IP address of the person you want to connect with. But before that, let’s understand public and private IP addresses.

Public and Private IP Addresses

Just like each SIM card has a unique number, every device needs a unique address on the internet to send and receive data.

With the rapid growth in internet users, assigning a unique public IP to every device isn't possible (due to IPv4 exhaustion). So instead, most devices are assigned private IP addresses by routers.

Public IP Address

This is what allows your device to access the internet.
It’s unique globally and exposed to the outer world.
Typically, only the router is assigned a public IP, and it communicates with the internet on behalf of all devices connected to it.

No two devices on the internet can have the same public IP.

Private IP Address

Assigned to devices inside a local network (by the router).
Can’t directly access the internet.
Managed through a process called NAT (Network Address Translation).

So how do you surf the internet with a private IP?

Here’s how:

When your device makes a request (e.g., opens a website), it goes to the router.
The router forwards this request using its public IP.
When the response comes back, it knows which device made the request and sends the data accordingly.

TURN/ICE Servers

Now that you know about private and public IPs, let’s talk about TURN and ICE servers.

After a device gets its private IP, it still doesn’t know its public IP, which is needed to establish a connection. That’s where these come in:

STUN/TURN servers are simple services that see the public IP of incoming requests and send it back to the client.
This way, the client becomes aware of its public IP address.

ICE (Interactive Connectivity Establishment) is a framework that uses STUN and TURN to find the best route between two peers.

Signaling Server

At this point, each user has the necessary information to establish a WebRTC connection—like codecs, IPs, ports, etc. This data is packaged in something called a Session Description Protocol (SDP).

But here's the catch:

You don’t have the other user’s SDP.
They don’t have yours.

So, we need a signaling server to exchange this information.
Don’t worry—it’s a simple server that:

Takes the SDP of User A and sends it to User B.
Takes the SDP of User B and sends it to User A.

Now both users have each other’s details and can establish a direct WebRTC connection. After that, the signaling server isn’t needed anymore.

Drawbacks

Since WebRTC is peer-to-peer, only two users can connect at a time by default. You can’t host large video conferences using just this architecture.

This is perfect for apps like Omegle, where only two users need to connect. But for more users, we need other methods.

Mesh Topology (Not Ideal)

In mesh, each user connects directly to every other user.

Example: In a 4-user call, each user maintains 3 separate connections.

This quickly becomes:

Bandwidth-heavy
Hard to scale
Difficult to keep all streams in sync

That’s why mesh is rarely used in production apps.

Solution – SFU (Selective Forwarding Unit) and Multipoint Control Units (MCUs)

To solve the issue of scalability in WebRTC for group calls, we use SFU (Selective Forwarding Unit) or MCU (Multipoint Control Unit) as per the requirement. In both cases, we introduce a server into the architecture.

In these setups, a server acts like a virtual client, and all the users are connected to this server using a P2P configuration. This server handles the media streams from all users. In case of SFU, it simply forwards the streams to other users. In MCU, it combines all the streams into one and sends it back. This makes the data easier to manage, keeps it in sync, and helps in scaling the system to support many users at once. This is how big platforms like Google Meet, Zoom, Discord, Microsoft Teams, etc., manage large group calls.

SFU (Selective Forwarding Unit)

In SFU, each user sends their video/audio stream to the server, and the server’s job is just to **forward those streams **to the other users. It doesn’t mix or edit the media—it just acts like a smart postman.

This way, each user only needs to upload their stream once, and the server takes care of distributing it to everyone else. Since the server isn’t doing any processing, this setup is lightweight and scalable.

But there’s a catch. Each user still receives multiple streams—one from each participant—so the client device has to handle that load. Still, it’s much better than mesh topology, where everyone connects with everyone directly.

That’s why SFU is the go-to choice for group video calls in real-world apps. It's efficient, requires less server power, and performs well even with 10, 20, or more users.

MCU (Multipoint Control Unit)

In this setup, things work a bit differently. All users send their streams to the server, just like in SFU. But here, the server does a lot more—it mixes all the streams into one combined video (usually a grid of faces) and sends that single stream back to every user.

This keeps everything perfectly in sync and makes life easier for the client. Each device only needs to handle one incoming stream. But this also means the server is doing all the heavy lifting—mixing, encoding, and streaming—which requires a lot more processing power and resources.

MCU setups are great for situations like webinars or classrooms, where it’s more important for everything to be in sync, and where users don’t interact much.

Conclusion

With that, this article comes to an end. I hope you learned something new—because this was new to me too, and I thought, why not share my understanding with others?

Thanks for reading, and I hope you enjoyed the article.

Till we meet again—seeya, have a great day, keep learning, peace out.

Signing off.