DEV Community: Jatin Gupta

Have you ever wondered how Zoom works?

Jatin Gupta — Fri, 12 Jun 2026 03:22:08 +0000

If only two people are talking, does Zoom send the video?
And if 100 people join a meeting, how can everyone see each other without your laptop sending 99 separate videos?
Let's understand the complete architecture (Peer-to-Peer (P2P), WebRTC, and SFU) in a simple way.

The Basic Idea

Whenever you join a Zoom meeting, there are actually multiple types of data traveling over the internet:

🎤 Audio
🎥 Video
💬 Chat messages
📄 Live transcript
🖥️ Screen sharing

These are called Real-Time Media Streams because they need to reach everyone almost instantly.

You
   │
   ├── Audio
   ├── Video
   ├── Chat
   ├── Screen Share
   └── Transcript
        │
        ▼
      Zoom
        │
        ▼
Other Participants

What happens in a 1-on-1 call?

Suppose:

You
Your friend

Only two participants exist.
In this case, Zoom can establish a Peer-to-Peer (P2P) connection.

You  ------------------> Friend
        Direct Connection

Your laptop sends one video stream directly to your friend's laptop.
Similarly,

Friend -------------> You

One stream each.
No complicated routing is required.

How do two devices connect?
They usually use WebRTC (Web Real-Time Communication).

WebRTC allows browsers and applications to exchange:

Video
Audio
Data in real time. However, before sending media, both devices need to discover each other.

This process is called Signaling.

Example:

You
   │
Signaling
   │
STUN Server
   │
Signaling
   │
Friend

After exchanging connection information, media can flow directly.

You  ==========> Friend
        Video

Friend ========> You
        Video

What is a STUN Server?
A STUN Server helps devices discover their public IP address and determine how they can communicate through NAT (Network Address Translation).
Think of it like this:

You ask,

"What address does the outside world see for me?"

The STUN server replies with that information so the two peers can attempt a direct connection.

Why P2P is great.

Advantages:

Very low latency
Less server cost
Fast communication
Direct transmission

You ---> Friend

Simple and efficient.

But what happens when more people join?
Imagine:

You
Person B
Person C

Now you must send your video to both people.

You now upload 2 streams.

Suppose there are 10 participants.

        You
      / / | \ \
     A B C D E F G H I

Now your laptop must upload 9 different video streams.
That is a huge problem.

Why is this impossible?

Because your:

Internet upload bandwidth is limited
CPU is limited
Memory is limited
Battery is limited If each stream is 2 Mbps,

For 10 people:

2 Mbps × 9

= 18 Mbps upload

Most users cannot continuously upload this much.
If 100 participants exist:

2 Mbps × 99

≈198 Mbps upload

Practically impossible.

So how does Zoom solve this?
Instead of sending separate streams to everyone,
You upload only one stream.

You
   │
   │
   ▼
 Zoom Server

The Zoom server then distributes that stream to everyone else.

             You
              │
              ▼
        Zoom Server
        /    |     \
       /     |      \
      B      C       D

Your laptop uploads only once.
The server does the rest.

This server is called SFU
SFU stands for
Selective Forwarding Unit

It is a media server.
Its job is simple:

Receive your stream
Forward it to other participants It does not create new videos. It simply forwards them intelligently.

How SFU works
Step 1

You upload one stream.

You
   │
   ▼
 SFU

Step 2

SFU receives it.

You
   │
   ▼
 SFU

Step 3

SFU forwards it.

        SFU
      /  |  \
     /   |   \
    B    C    D

Now each participant does the same.

Everyone uploads only one stream.
The SFU distributes everything.

Why is it called "Selective" Forwarding?
Because it forwards only what is needed.
Example:

If your screen shows only 9 participants,
The SFU may send only those visible videos in high quality.
If someone is hidden or inactive,
The server can reduce quality or stop forwarding temporarily.

This saves:

Bandwidth
CPU
Battery

Does SFU mix videos together?
No.
It simply forwards.

You ---> SFU ---> B

You ---> SFU ---> C

You ---> SFU ---> D

No video mixing happens.

Then what is MCU?
Another architecture is MCU (Multipoint Control Unit).
MCU receives all streams,

A
 \
  \
B ---> MCU
  /
 /
C

It decodes everything,
mixes videos,
creates one combined video,
then sends that back.

        MCU
          │
          ▼
     Combined Video
          │
          ▼
     All Participants

SFU vs MCU

| SFU                              | MCU                              |
| -------------------------------- | -------------------------------- |
| Simply forwards streams          | Mixes streams                    |
| Faster                           | More processing                  |
| Lower latency                    | Higher latency                   |
| Less CPU on server               | Heavy server computation         |
| Scales well                      | More expensive                   |
| Used by many modern meeting apps | Used in some specialized systems |

Why Zoom uses SFU
Because it allows:

Millions of users
Lower latency
Better scalability
Lower upload requirements
Efficient bandwidth usage Instead of every laptop sending many streams,

❌ You → B
❌ You → C
❌ You → D
❌ You → E

it becomes

✅ You
      │
      ▼
     SFU
   / / | \ \
  B C D E F

Only one upload from your device.

Complete Flow

User

   │

Capture Camera

   │

Encode Video

   │

Upload One Stream

   │

──────────────

       SFU

──────────────

Receives Stream

Forwards Stream

──────────────

Participants

B

C

D

E

F

Final Takeaway

1-on-1 calls can often use Peer-to-Peer (P2P) with WebRTC, where devices communicate directly after signaling and STUN-based connection setup.
Group calls cannot rely on P2P because each participant would need to upload many separate streams, quickly exhausting bandwidth and device resources.
To solve this, Zoom uses an SFU (Selective Forwarding Unit). Each participant uploads one media stream to the SFU, and the SFU intelligently forwards that stream to the other participants.
This architecture keeps latency low, reduces upload bandwidth requirements, and allows Zoom to scale to meetings with many participants efficiently.

In one line:
"P2P works well for 1-to-1 calls, but for group meetings Zoom scales by using an SFU, where you upload one stream and the server forwards it to everyone else."

How URL Shorteners Generate Unique Links Instantly

Jatin Gupta — Thu, 11 Jun 2026 08:41:19 +0000

Every day, billions of links are shared through services like Bitly, TinyURL, and many custom URL shorteners.
But have you ever wondered:
How can they generate unique short URLs instantly, even when millions of users are creating links at the same time?
Let's understand the complete system step by step-

What is a URL Shortener?
A URL shortener converts a long URL into a shorter and easier-to-share URL.
Example
Long URL:

https://www.example.com/blog/how-url-shorteners-work-in-distributed-systems

Short URL:

https://short.ly/g8

When someone opens short.ly/g8, the service redirects them to the original long URL.

The Main Challenge
Imagine:

Millions of users creating links
Thousands of requests every second
No duplicate short URLs allowed

The system must:

✅ Generate links quickly

✅ Never create duplicates

✅ Scale to millions of users

✅ Keep URLs short

Approach 1: Using URL Prefix
One simple method is:
Take the first few characters of the original URL.

Example:

https://linkedin.com/jobs
→ link

Problem:
Many URLs start with the same letters.

https://linkedin.com/jobs
https://linkedin.com/feed
https://linkedin.com/profile

All become:

link

This creates collisions.
Therefore, real-world systems don't use this approach.

Approach 2: Unique Counter + Base62 Encoding
This is one of the most common approaches used in large systems.
The process looks like:

User submits URL
        ↓
Generate unique ID
        ↓
Convert ID to Base62
        ↓
Store mapping
        ↓
Return short URL

Step 1: User Sends Long URL
Example:

https://www.linkedin.com/posts/example-post

The request reaches the backend server.

Step 2: Generate a Unique Number
Instead of generating random strings, the system first generates a unique number.
Example:

Every new URL gets the next number.

Why Not Use Database Auto Increment?
Databases can generate IDs, but under very high traffic:

Database becomes a bottleneck
Slower performance
Increased load Therefore, many systems use Redis.

What is Redis?
Redis is an extremely fast in-memory database.
It stores data in RAM instead of disk.
Because RAM is much faster than disk:

Database → milliseconds
Redis → microseconds

This makes Redis perfect for counters.

Redis INCR Command
Redis provides a command called:

INCR

It increases a number by 1.

Example:

Counter = 1000

Request 1:
INCR
→ 1001

Request 2:
INCR
→ 1002

Request 3:
INCR
→ 1003

Why Redis INCR Is Special
Redis operations are atomic.
Atomic means:

Only one operation happens at a time.

Even if:

1 million requests arrive simultaneously

Redis guarantees:

No duplicates.
No race conditions.
No conflicts.
This is why Redis is commonly used in URL shortening systems.

What Is a Race Condition?
Imagine two users create a URL at exactly the same moment.
Without atomic operations:

User A gets ID 1001
User B gets ID 1001

Now both URLs have the same short code.
System breaks.
Redis prevents this problem.

Step 3: Convert Number to Base62
Now we have:

Using this directly would make URLs long.
So we convert it into Base62.

What Is Base62?
Base62 uses:

a-z  → 26 characters
A-Z  → 26 characters
0-9  → 10 characters

Total:

26 + 26 + 10 = 62 characters

Character set:

abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789

Why Base62?
Because it is:

✅ URL friendly

✅ Compact

✅ Easy to encode

✅ No special characters

Example Base62 Conversion
Suppose:

1000 → g8
1001 → g9
1002 → ga

Now:

https://short.ly/g8

Is much shorter than:

https://short.ly/1000

How Base62 Conversion Works
Think of it like converting:

Decimal → Binary

But instead:

Decimal → Base62

Example:

1000 ÷ 62

Repeated division generates characters from the Base62 character set.
The resulting string becomes the short code.

How Many URLs Can Base62 Create?

Formula:

62ⁿ

Where:

62 = available characters
n = length of short code

1 Character

62 combinations

2 Characters

62² = 3,844

3 Characters

62³ = 238,328

6 Characters

626ⁿ

Result:

56,800,235,584

Over 56 billion URLs.

Step 4: Store Mapping
The system saves:
Short Code

| Short Code | Original URL                                                           |
| ---------- | ---------------------------------------------------------------------- |
| g8         | [https://example.com/very-long-url](https://example.com/very-long-url) |
| g9         | [https://linkedin.com/post](https://linkedin.com/post)                 |
| ga         | [https://youtube.com/watch?v=abc](https://youtube.com/watch?v=abc)     |

Database record:

{
  "id": 1000,
  "shortCode": "g8",
  "originalUrl": "https://example.com/very-long-url",
  "createdAt": "2026-06-08",
  "expiryDate": null
}

Step 5: Return Short URL
Backend returns:

https://short.ly/g8

The user can now share this URL anywhere.

Step 6: Redirection Process
When someone visits:

https://short.ly/g8

The backend:

Reads g8
Finds corresponding URL
Returns HTTP redirect

Example:

g8
↓
Database lookup
↓
Original URL found
↓
302 Redirect
↓
User reaches destination

Why Not Use Random Strings?

Example:

a8KzP1

Random generation causes problems:

Collision checks required
More database queries
Slower performance

Example:

Generated:
abc123

Already exists?

Need extra lookup.
Counter + Base62 avoids this completely.

System Design Used by Large Companies

A simplified architecture:

Client
  ↓
Load Balancer
  ↓
Application Servers
  ↓
Redis (INCR Counter)
  ↓
Database

Redis
Generates unique IDs.

Application Server

Converts IDs to Base62.

Database

Stores URL mappings.

Load Balancer

Distributes traffic among servers.

Interview Question: Why Base62 Instead of Base64?
Many people confuse Base62 and Base64.

Base64 Characters

A-Z
a-z
0-9
+
/

Problem:

+
/
=

Special characters are not ideal inside URLs.

Example:

ab+c/

Needs encoding.

Base62 Characters

a-z
A-Z
0-9

No special characters.
Completely URL-friendly.
Therefore URL shorteners usually use Base62, not Base64.

Real-World Optimizations
Large URL shorteners also add:

Caching
Frequently accessed URLs stay in Redis.

Analytics

Track:
Click count
Device type
Browser
Country

Expiration
Links can expire automatically.

Custom Aliases

short.ly/jatin

instead of:

short.ly/g8

Final Summary

A modern URL shortener works like this:

User submits URL
        ↓
Redis INCR generates unique ID
        ↓
ID converted to Base62
        ↓
Mapping stored in database
        ↓
Short URL returned
        ↓
User opens short URL
        ↓
Database lookup
        ↓
Redirect to original URL

Key Takeaways

Redis INCR generates unique IDs atomically.
Atomic operations prevent duplicate URLs.
Base62 makes IDs short and URL-friendly.
6 Base62 characters can generate over 56 billion unique combinations.
This approach is fast, scalable, and widely used in production URL shortening systems.

This is why services like Bitly can create unique short URLs almost instantly, even when handling millions of requests every second. 🚀