Forem: rajat

Why We Don't Use Socket Connections for Everything

rajat — Fri, 06 Mar 2026 17:00:25 +0000

Sockets (such as TCP sockets or WebSockets) enable persistent, two-way communication between a client and a server. Because of this, they are extremely useful for real-time applications like chat systems, live notifications, and online games.

However, in most web applications we do not use socket connections for every request. Instead, many systems still rely on HTTP-based communication.

Let’s explore why.

1. Persistent Connections Consume More Resources

A socket connection remains open for a long time.

Example:

Client ⇄ Server

The server must maintain this connection in memory and keep track of its state.

If a system has 1 million users connected simultaneously, the server must maintain 1 million open connections.

This requires:

Memory for each connection
CPU for connection management
File descriptors from the operating system

Because of these costs, keeping many persistent connections can become expensive and difficult to scale.

In contrast, HTTP connections are usually short-lived:

Client → Request → Server → Response → Connection closed

Once the response is sent, the server can release the resources.

2. Many Applications Do Not Need Real-Time Communication

Socket connections are best suited for real-time systems, such as:

Chat applications
Multiplayer games
Stock trading dashboards
Live notifications

However, most web operations follow a simple request–response pattern.

Examples include:

User login
Fetching product lists
Loading a webpage
Submitting a form

In these cases, HTTP is simpler and more efficient.

3. Load Balancing Becomes More Difficult

With HTTP, every request is independent.

Client → Load Balancer → Any Server

Requests can be distributed easily across many servers.

Socket connections, however, are long-lived:

Client ⇄ Server (persistent connection)

Once a socket is established, the client must continue communicating with the same server. This can make load balancing and horizontal scaling more complex.

4. Operating System Limits

Operating systems impose limits on the number of simultaneous socket connections a server can handle.

Examples include:

Maximum open file descriptors
Network port limits
Memory limits per connection

If a server tries to maintain millions of open sockets, it may hit these system limits.

5. Increased Development Complexity

Socket-based systems require additional logic to handle:

Connection management
Reconnection strategies
Heartbeats and keep-alive signals
Message ordering
State synchronization

HTTP APIs are generally much simpler to implement and maintain.

Comparison: HTTP vs Socket Connections

Feature	HTTP	Socket / WebSocket
Connection Type	Short-lived	Persistent
Communication	Request–response	Bi-directional
Server Resource Usage	Lower	Higher
Best Use Cases	APIs, web pages	Real-time applications
Complexity	Simple	More complex

Conclusion

Although socket connections enable powerful real-time communication, they are not suitable for every situation.

Most modern architectures use a hybrid approach:

HTTP for standard API communication
WebSockets or sockets for real-time features

By combining both approaches, systems can achieve efficient resource usage while still supporting real-time interactions when needed.

How Vector Clocks Work in Distributed Systems

rajat — Fri, 06 Mar 2026 16:45:28 +0000

In distributed databases, multiple servers replicate the same data to improve availability and scalability. However, concurrent updates to the same data item can lead to conflicts because different replicas may process writes independently.

To detect and resolve these conflicts, distributed systems often use vector clocks.

A vector clock helps determine whether two versions of data are:

Ordered (one happened after another)
Concurrent (a conflict exists)

What Is a Vector Clock?

A vector clock is a collection of [server, version] pairs associated with a data item.

It tracks which server modified the data and how many updates that server has made.

A vector clock can be represented as:

D([S1, v1], [S2, v2], …, [Sn, vn])

Where:

D → data item
Si → server ID
vi → version counter for that server

When a server writes a data item:

If [Si, vi] already exists → increment vi
Otherwise → create a new entry [Si, 1]

Example: How Vector Clocks Work

Let’s walk through the example shown in the diagram.

1. First Write

A client writes data item D1.

The write is handled by server Sx.

Vector clock becomes:

D1([Sx, 1])

This means server Sx has processed the first version of the data.

2. Second Update

Another client reads D1, updates it, and writes it back.

The write is again handled by Sx.

The counter for Sx increments:

D2([Sx, 2])

This version descends from D1, so it overwrites the previous version.

3. Update by Another Server

A client reads D2, modifies it, and the write is handled by Sy.

Vector clock becomes:

D3([Sx, 2], [Sy, 1])

This indicates:

Two updates occurred on Sx
One update occurred on Sy

4. Concurrent Update

Another client also reads D2, modifies it, and writes through Sz.

Vector clock becomes:

D4([Sx, 2], [Sz, 1])

Now the system has two different versions:

D3([Sx,2], [Sy,1])
D4([Sx,2], [Sz,1])

These updates occurred independently, creating a conflict.

5. Conflict Resolution

When a client reads both D3 and D4, it detects a conflict.

This happened because D2 was modified by both Sy and Sz.

The client reconciles the conflict and writes a new version handled by Sx.

Vector clock becomes:

D5([Sx, 3], [Sy, 1], [Sz, 1])

This new version incorporates both updates.

Detecting Conflicts Using Vector Clocks

Vector clocks allow systems to determine relationships between versions.

Ancestor Relationship (No Conflict)

Version X is an ancestor of Y if every counter in Y is greater than or equal to X.

Example:

D([s0,1], [s1,1])
D([s0,1], [s1,2])

Since every counter in the second version is greater or equal, the first version preceded the second.

Therefore:

No conflict exists.

Sibling Relationship (Conflict)

Two versions are siblings if neither dominates the other.

Example:

D([s0,1], [s1,2])
D([s0,2], [s1,1])

Here:

First version has higher s1
Second version has higher s0

Because neither version fully dominates the other, they are concurrent.

Therefore:

A conflict exists.

Downsides of Vector Clocks

Although vector clocks are powerful, they have some drawbacks.

1. Client Complexity

Clients must implement conflict resolution logic, which increases application complexity.

2. Growing Vector Size

The number of [server, version] pairs may grow quickly as more servers update the data.

To control this, systems often:

Set a maximum vector size
Remove the oldest entries

However, removing entries can make it harder to determine exact ancestor relationships.

Final Thoughts

Vector clocks are a fundamental technique used in distributed systems to detect causal relationships between updates.

They help distributed databases:

Detect concurrent writes
Identify conflicting versions
Allow applications to reconcile conflicts safely

Systems such as Amazon DynamoDB introduced vector clocks to maintain eventual consistency while preserving high availability.

Despite their complexity, vector clocks remain one of the most effective mechanisms for conflict detection in distributed databases.

Inconsistency Resolution in Distributed Systems: Versioning

rajat — Fri, 06 Mar 2026 16:34:28 +0000

Modern distributed databases such as Amazon DynamoDB and Apache Cassandra replicate data across multiple servers to improve scalability, fault tolerance, and availability.

However, replication introduces a major challenge: data inconsistency during concurrent updates.

To address this problem, distributed systems use a technique called versioning.

In this article, we’ll explore why versioning is needed, how it works, and how it helps resolve conflicts in eventually consistent systems.

Why Versioning Is Needed

In an eventually consistent system, updates do not reach all replicas at the same time due to network delays or partitions.

Consider a system with three replicas:

N = 3
Replicas: s0, s1, s2

Two clients update the same key at the same time:

Client A → put(key1 = 10)
Client B → put(key1 = 20)

Because of network delays, the replicas may temporarily store different values:

s0 = 10
s1 = 20
s2 = 10

Now the system contains conflicting values for the same key.

This situation is called a write conflict.

What Versioning Does

Versioning allows the system to track the history of writes.

Each update is assigned a version identifier.

Example:

(key1, value = 10, version = v1)
(key1, value = 20, version = v2)

Instead of immediately overwriting data, the system may temporarily store multiple versions of the same value.

This helps the system determine:

Which write happened earlier
Whether two writes occurred concurrently

Two Possible Scenarios

1. One Version Is Newer

v1 → value = 10
v2 → value = 20

If the system detects that v2 happened after v1, then the newer version replaces the older one.

v2 replaces v1

In this case, no conflict occurs because the system knows the correct order of writes.

2. Concurrent Versions

Sometimes the system cannot determine the order of writes.

Example:

v1 → value = 10
v2 → value = 20

These updates are considered concurrent.

Instead of choosing one automatically, the database may return both versions:

key1:
 value1 = 10
 value2 = 20

Now the client application must resolve the conflict.

Client Reconciliation

The application decides how to resolve conflicting values.

Common strategies include:

1. Last Write Wins

The system selects the value with the latest timestamp.

Latest timestamp → chosen value

2. Merging Values

Sometimes values can be combined instead of overwritten.

Example in a shopping cart system:

cart1 = {apple}
cart2 = {banana}

Merged result:

cart = {apple, banana}

This approach ensures that no data is lost.

3. Application Logic

The application can apply custom business rules to determine the correct value.

For example:

Priority-based updates
User-based conflict resolution
Domain-specific merge logic

Versioning with Vector Clocks

Some distributed databases use vector clocks to track the history of updates.

A vector clock stores a list of node counters representing update history.

Example:

v1 = {s0:1}
v2 = {s1:1}

If two versions have different histories, the system treats them as concurrent updates.

Vector clocks help databases automatically detect conflicts without relying only on timestamps.

Key Takeaways

Versioning allows distributed databases to:

Detect conflicting updates
Temporarily store multiple versions of data
Resolve conflicts through reconciliation strategies

This approach enables eventual consistency while keeping the system highly available and scalable.

Final Thoughts

Versioning is a fundamental technique in distributed systems. It allows modern databases to maintain consistency without blocking writes, which is critical for systems operating at large scale.

By tracking the history of updates and allowing conflict resolution later, versioning ensures that distributed systems remain reliable, flexible, and highly performant.

Understanding WebSocket Connection (Simple Explanation)

rajat — Fri, 06 Mar 2026 16:25:39 +0000

WebSocket is a protocol used for real-time communication between a client and a server. Unlike normal HTTP communication, WebSocket allows continuous, two-way communication over a single connection.

1. WebSocket Connection is Initiated by the Client

A WebSocket connection always starts from the client side (browser, mobile app, or any client application).

The client sends a request to the server asking to upgrade the connection to WebSocket.

Example HTTP request headers:

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade

If the server supports WebSocket, it responds with:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

This process is called the WebSocket Handshake.

After this handshake, the protocol switches from HTTP to WebSocket.

2. WebSocket is Bi-Directional

In traditional HTTP communication:

Client → Request
Server → Response

The server cannot send data unless the client first sends a request.

But in WebSocket:

Client ⇄ Server

Both the client and the server can send messages at any time without waiting for a request.

This makes WebSocket ideal for real-time applications.

Examples:

Chat applications
Online gaming
Live notifications
Stock price updates
Real-time dashboards

3. WebSocket Connection is Persistent

A WebSocket connection remains open for a long time.

Unlike HTTP where the connection is closed after each response, WebSocket maintains a persistent connection.

This allows continuous communication like:

Client ⇄ Server
Client ⇄ Server
Client ⇄ Server

Because the connection stays open, it reduces the overhead of repeatedly creating new HTTP connections.

4. WebSocket Works Through Firewalls

Many networks use firewalls that restrict unknown ports.

However, WebSocket usually runs on the same ports used by HTTP and HTTPS:

Port 80 → ws:// (WebSocket)
Port 443 → wss:// (Secure WebSocket)

Since these ports are commonly allowed by firewalls, WebSocket connections generally work without issues.

5. Why WebSocket is Important

WebSocket is widely used in modern applications because it enables low-latency and efficient communication.

Benefits include:

Real-time data updates
Lower network overhead
Persistent connection
Full duplex communication (two-way communication)

Conclusion

A WebSocket connection:

Is initiated by the client
Starts as an HTTP connection
Uses a handshake to upgrade to WebSocket
Becomes a persistent connection
Allows bi-directional communication
Works easily through firewalls using ports 80 and 443

Because of these features, WebSocket is one of the most important technologies used for building real-time web applications.

Convert any Github Repo to VS Code Environment

rajat — Sun, 09 Jul 2023 16:05:35 +0000

To open a GitHub repository in GitHub.dev, you can follow these steps:

Go to the GitHub website and find the repository you want to open. For example, let's say you want to open the repository [example/repo](https://github.com/example/repo).
In the URL, locate the .com portion, which in this case is github.com.
Swap the .com with .dev in the URL. So, in our example, github.com becomes github.dev.
The updated URL would be [https://github.dev/example/repo](https://github.dev/example/repo).
Open a new tab in your web browser and paste the updated URL into the address bar.
Hit Enter or Return to navigate to the URL.
The GitHub repository will now open in GitHub.dev, providing you with a web-based code editor environment powered by Visual Studio Code.
From here, you can edit the code, view branches, open pull requests, and collaborate with others in real-time, all within the GitHub.dev environment.

Remember, this process allows you to open a GitHub repository directly in GitHub.dev without needing to download or install any additional software. It provides a convenient way to quickly access and work on your code within a web-based IDE.