DEV Community: Ashay Tiwari

How HTTP Works Under the Hood: TCP, UDP, Keep-Alive & HTTP/3 | Deeper Dive into HTTP #3

Ashay Tiwari — Tue, 27 Oct 2026 12:28:19 +0000

When you open a website, fetch data from an API, or submit a form, HTTP makes communication between your application and a server possible.

But have you ever wondered what happens after your application sends an HTTP request?

In this third article of the Deeper Dive into HTTP series, we'll explore:

How HTTP fits into the networking stack.
How TCP establishes reliable connections.
What happens during the TCP three-way handshake.
What UDP is and how it differs from TCP.
How Keep-Alive enables connection reuse.
Why HTTP/3 uses QUIC over UDP.

Let's dive in.

1. Understanding the Networking Stack

Before exploring TCP, UDP, and HTTP, let's understand how these protocols fit together.

Imagine your frontend needs to fetch a list of users from a backend API.

GET /users

There are multiple layers involved in getting this request to the server.

A simplified view of the networking stack looks like this:

Each layer has a different responsibility.

First, HTTP defines the rules for communication. It describes things like the request method, headers, status codes, and message content.

Next, TCP, when used, provides a reliable, ordered stream of bytes between two endpoints. It handles things like retransmission of lost data and flow control.

UDP provides a lightweight way to send datagrams without built-in guarantees of delivery, ordering, or retransmission.

And then there's IP, which helps route packets across networks toward their destination.

Think of it this way.

HTTP defines what the message means. TCP helps deliver a reliable stream of data. And IP helps move packets through the network.

For example, HTTP defines what a GET /users request means. TCP can provide reliable delivery of the bytes carrying that HTTP message, while IP handles packet addressing and routing.

2. How Does TCP Establish a Connection?

TCP stands for Transmission Control Protocol.

Before sending HTTP data over a new TCP connection, the client and server typically establish the connection using something called the TCP three-way handshake.

It involves three steps.

Step one: SYN.

The client sends a TCP segment with the SYN flag set.

It is essentially initiating the connection and proposing its initial sequence number.

Step two: SYN-ACK.

The server responds with a segment containing both SYN and ACK flags.

It acknowledges the client's initial sequence number and provides its own.

Step three: ACK.

The client acknowledges the server's initial sequence number.

At this point, the TCP handshake is complete, and both sides can exchange application data.

And now, the TCP connection is established.

Once the connection is ready, HTTP data can be sent over it.

Does the HTTP request come immediately after the handshake?

Not necessarily.

For HTTPS over TCP, the client and server typically also establish TLS security before exchanging ordinary HTTP application data. TLS provides encryption, integrity protection, and server authentication.

So, a simplified connection setup looks like this:

Here's something important: this handshake happens when a new TCP connection is established. It doesn't need to happen before every HTTP request.

And that's where connection reuse becomes important.

3. What Is UDP, and How Is It Different from TCP?

UDP stands for User Datagram Protocol.

Like TCP, UDP operates at the transport layer. However, it provides a different set of capabilities.

TCP establishes a connection and provides reliable, ordered delivery of a byte stream.

UDP sends independent datagrams without providing built-in mechanisms for reliable delivery, retransmission, or ordered delivery.

Let's compare them.

UDP has less built-in transport machinery, but that doesn't mean every UDP application is unreliable.

An application can implement additional mechanisms on top of UDP when it needs them.

And this is exactly where QUIC becomes important.

Why does HTTP/3 use UDP?

If TCP already provides reliable delivery, why build a new transport protocol over UDP?

The answer involves connection setup, encryption, and how multiple streams behave when packets are lost.

TCP provides one ordered byte stream per connection. If TCP cannot deliver a missing portion of that stream, later bytes in the same stream cannot be delivered to the application in order until the gap is resolved.

With HTTP/2, multiple HTTP streams can share one TCP connection. A lost TCP segment can therefore delay delivery of data for multiple streams on that connection.

HTTP/3 uses QUIC to address important limitations of this architecture.

QUIC implements reliability, congestion control, stream multiplexing, and integrated TLS 1.3 security over UDP.

UDP is the underlying datagram transport; QUIC supplies the transport features needed by HTTP/3.

4. What Is Keep-Alive in HTTP?

Now let's look at another important concept: connection reuse.

Imagine your frontend needs to make five API requests to the same server.

For example:

GET /api/profile
GET /api/posts
GET /api/notifications
GET /api/settings
GET /api/followers

If every request required a new TCP connection, the client would repeatedly incur connection setup overhead.

For HTTPS over TCP, new connections can also require a TLS handshake.

That adds work and can increase latency.

Without connection reuse

A simplified sequence might look like this:

Request 1 → Establish connection → Response 1
Request 2 → Establish connection → Response 2
Request 3 → Establish connection → Response 3

This example assumes the client closes or doesn't reuse each connection. Real clients may reuse connections even when applications make separate requests.

With persistent connections

Instead, the client can keep a connection open and reuse it for additional HTTP exchanges.

Establish connection
        |
        v
Request 1 → Response 1
        |
        v
Request 2 → Response 2
        |
        v
Request 3 → Response 3
        |
        v
Connection remains available for reuse

This reduces repeated connection setup overhead and can improve performance.

How does HTTP Keep-Alive work?

In HTTP/1.1, persistent connections are the default unless the connection is otherwise closed or a message explicitly indicates that it should close.

For example:

GET /api/profile HTTP/1.1
Host: example.com

The client and server can reuse the connection for additional requests.

A server might also send:

Connection: keep-alive

However, this header is not required to enable persistence in HTTP/1.1.

In HTTP/1.0, persistent connections were commonly negotiated using the Connection: keep-alive convention.

What happens in HTTP/2 and HTTP/3?

Connection reuse becomes even more powerful with modern HTTP versions.

HTTP/2 supports multiplexing multiple independent HTTP streams over a single TCP connection.

HTTP/3 also supports multiplexing, but it uses QUIC streams over a QUIC connection instead of HTTP/2's streams over TCP.

This means multiple requests can make progress concurrently without requiring a separate connection for every request.

We'll explore that distinction further in the next section.

5. HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP has evolved over time to improve performance, efficiency, and communication behavior.

HTTP/1.1: Persistent connections

HTTP/1.1 allows multiple requests and responses to reuse the same connection.

However, it doesn't natively multiplex independent HTTP exchanges in the way HTTP/2 does. On a single connection, responses must be sent in request order, so a slow response can delay later responses.

Browsers historically worked around some of these limitations by opening multiple connections to a server.

HTTP/2: Multiplexing over TCP

HTTP/2 introduces multiplexing, which allows multiple streams to share a single TCP connection.

For example:

One TCP connection
    ├── Stream 1: Profile request
    ├── Stream 3: Posts request
    ├── Stream 5: Settings request
    └── Stream 7: Notifications request

The streams can be interleaved, allowing requests and responses to make progress concurrently.

But there is an important limitation.

TCP still provides one ordered byte stream. If a TCP segment is lost, TCP cannot deliver subsequent bytes to the application in order until the missing data is recovered.

As a result, data from multiple HTTP/2 streams sharing that connection can experience transport-level head-of-line blocking.

HTTP/3: QUIC over UDP

HTTP/3 uses QUIC rather than TCP.

QUIC provides reliable delivery within its streams while allowing data from independent streams to progress separately.

One QUIC connection
    ├── Stream 1: Profile request
    ├── Stream 3: Posts request
    ├── Stream 5: Settings request
    └── Stream 7: Notifications request

If packet loss affects data belonging to one stream, other streams can continue delivering available data rather than waiting for a single ordered TCP byte stream to recover.

This doesn't mean packet loss has no impact on other streams. Streams can still share network capacity and congestion control, and loss can delay any data that depends on the missing information.

QUIC also integrates TLS 1.3 security into its connection establishment. Depending on the connection setup and whether session resumption or 0-RTT is available, it can reduce the number of round trips needed before application data is sent.

These improvements can make HTTP/3 particularly useful on networks with higher latency or changing connectivity.

6. What Should Developers Take Away?

You don't need to implement TCP, UDP, or QUIC yourself to build most web applications. Browsers, operating systems, networking libraries, and servers handle these protocols.

However, understanding them helps explain real-world behavior.

If a new connection is slow, connection establishment and TLS negotiation may contribute to latency.
If an application makes many requests to the same server, connection reuse can reduce overhead.
If multiple resources are fetched concurrently, HTTP/2 and HTTP/3 multiplexing can improve efficiency.
If a network has packet loss, the transport protocol can influence how that loss affects application data.
If a connection changes networks, QUIC can support connection migration in scenarios where its connection identifiers and network conditions allow it.

These concepts are useful when investigating API latency, performance bottlenecks, browser networking behavior, and modern web infrastructure.

Conclusion

HTTP is more than a format for sending requests and receiving responses. Its performance also depends on the transport protocols and connection-management mechanisms underneath it.

Here's a quick recap:

TCP provides reliable, ordered byte-stream delivery and establishes connections through a three-way handshake.

UDP sends datagrams without built-in delivery or ordering guarantees.

Keep-Alive and persistent connections allow connection reuse and reduce repeated setup overhead.

HTTP/2 adds multiplexing over TCP, but TCP-level head-of-line blocking can affect all streams sharing a connection.

HTTP/3 uses QUIC over UDP to support reliable streams, multiplexing, integrated TLS 1.3 security, and improved handling of packet loss across independent streams.

This is the third article in the Deeper Dive into HTTP series by AshayCodes. In the next article, we'll explore HTTP methods such as GET, POST, PUT, PATCH, and DELETE, along with safe and idempotent methods.

Happy learning!

HTTP Requests, Responses, and Headers Explained with Examples | Deeper Dive into HTTP #2

Ashay Tiwari — Fri, 16 Oct 2026 08:16:22 +0000

Every time you open a website, fetch data from an API, submit a form, or upload a file, your application communicates with a server.

But what does that communication actually look like?

How does a browser tell a server which resource it wants? How does the server communicate whether the request succeeded? And how do they exchange information about authentication, caching, content types, and security?

The answer lies in three fundamental building blocks of HTTP communication:

Requests — messages sent by a client to a server.

Responses — messages returned by the server.

Headers — metadata that provides additional information about requests and responses.

In the previous article, we explored what HTTP is, why it is stateless, and how authentication works despite that statelessness.

Now, let's look at how HTTP messages are structured and how to understand them when working with APIs.

1. What Is an HTTP Request?

An HTTP request is a message sent by a client to a server to request a resource or perform an operation.

The client could be a browser, a mobile application, a frontend built with React, or another backend service.

For example, imagine that your frontend needs to fetch a list of users from a backend API.

It might send this request:

GET /api/users HTTP/1.1
Host: example.com
Accept: application/json

This tells the server that the client wants to retrieve the users resource and can accept a JSON response.

The structure of an HTTP request

A traditional HTTP/1.1 request has the following structure:

Request Line
Headers

Optional Blank Line + Message Body

Let's break it down.

1.1 Request line

The request line contains three parts:

GET /api/users HTTP/1.1

Method: GET — describes the intended operation.

Request target: /api/users — identifies the target resource.

HTTP version: HTTP/1.1 — identifies the HTTP version used by this message.

Other common HTTP methods include POST, PUT, PATCH, and DELETE. We'll explore them in a future article.

1.2 Request headers

Headers provide additional information about the request.

For example:

Host: example.com
Accept: application/json
Authorization: Bearer <access-token>
Content-Type: application/json

These headers communicate different things:

Host identifies the target host (where we are requesting a resource) in HTTP/1.1.

Accept describes the response media types the client can accept.

Authorization carries credentials used for authentication.

Content-Type describes the media type of the request body, when one is present.

Not every request needs every header. Their presence depends on the request and the application's requirements.

1.3 Request body

A request body carries data sent by the client.

For example, when creating a user, a client might send:

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
Accept: application/json

{
  "name": "Ashay",
  "email": "ashay@example.com"
}

Here, the body contains the user data in JSON format.

A request body is common with methods such as POST and PUT, but the HTTP method alone doesn't always determine whether a body can exist. For example, GET requests generally shouldn't include content unless a specific, well-defined use case supports it.

The server processes the request according to the endpoint's implementation, validation rules, authentication requirements, and business logic.

2. What Is an HTTP Response?

After receiving and processing a request, a server sends an HTTP response.

A response communicates the outcome of the request and may include the requested resource or other useful information.

For example:

HTTP/1.1 200 OK
Content-Type: application/json

[
  {
    "id": "101",
    "name": "John Doe"
  },
  {
    "id": "102",
    "name": "Jane Doe"
  }
]

In this example, the server returns a successful response containing a JSON array of users.

The structure of an HTTP response

A traditional HTTP/1.1 response has this structure:

Status Line
Headers

Optional Blank Line + Message Body

Let's examine each part.

2.1 Status line

The status line contains the HTTP version, status code, and a reason phrase in HTTP/1.1.

For example:

HTTP/1.1 200 OK

HTTP version: HTTP/1.1

Status code: 200

Reason phrase: OK

The status code communicates the outcome of the request.

2.2 Response headers

Response headers provide metadata about the response.

For example:

Content-Type: application/json
Cache-Control: no-cache
Set-Cookie: session_id=abc123; HttpOnly; Secure

These headers can tell the client how to interpret the response, how to handle caching, or whether to store a cookie.

2.3 Response body

The response body contains the returned representation or other response content, when applicable.

For example:

{
  "id": "101",
  "name": "John Doe",
  "role": "developer"
}

A response body is common when an API returns data, HTML, or an error document.

However, not every response includes a body. For example, a 204 No Content response indicates that the request succeeded and there is no response content to return.

3. What Are HTTP Headers?

We've already seen headers in both requests and responses. Now let's understand them in more detail.

HTTP headers are fields that carry metadata and control information associated with HTTP messages.

They help clients and servers communicate information beyond the request target or response status.

For example, headers can communicate:

Which media types the client accepts.
What format the request body uses.
Whether authentication credentials are present.
How a response can be cached.
Which security policies apply.
Information about content negotiation and representation metadata.

HTTP headers are generally written as field names followed by a colon and a value in HTTP/1.1:

Content-Type: application/json
Accept: application/json
Cache-Control: no-cache

Header names are case-insensitive, so Content-Type and content-type refer to the same field name.

Headers can appear in requests, responses, or both, depending on the field's defined purpose.

A quick note about HTTP versions

The examples in this article use the traditional HTTP/1.1 text format because it is easy to read and understand.

4. Different Types of HTTP Headers

For our understanding, we can group commonly encountered headers into several categories.

4.1 Request headers

Request headers provide information about the client, its preferences, the request context, or the credentials being presented.

Examples include:

Accept

Accept: application/json
Indicates that the client can accept JSON responses.

Authorization

Authorization: Bearer
Carries credentials used by the server to authenticate the request.

User-Agent

User-Agent: ExampleClient/1.0
Identifies the client software. The exact format and usefulness of this value depend on the client.

Origin

Origin: https://app.example.com
Identifies the origin associated with a request, particularly in browser security and CORS scenarios.

Request headers help the server understand the context of an incoming request, but their presence doesn't automatically make the request trustworthy. The server must validate security-sensitive information.

4.2 Response headers

Response headers provide information about the server's response and instructions or metadata for the client.

Examples include:

Set-Cookie

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax
Instructs the browser to store a cookie according to its attributes and cookie policies.

Location

Location: https://example.com/new-page
Identifies a URI associated with a redirect or another response that uses this field.

Cache-Control

Cache-Control: no-store
Directs caches not to store the response.

Access-Control-Allow-Origin

Access-Control-Allow-Origin: https://app.example.com
Indicates which origin is permitted by the server's CORS policy for browser-based cross-origin access.

Response headers often determine how browsers and other clients handle the response, rather than simply describing its content.

4.3 Representation and content-related headers

These headers help describe the representation being sent or provide information relevant to its interpretation.

Content-Type

Content-Type: application/json
Indicates the media type of the message content.

Content-Encoding

Content-Encoding: gzip
Indicates the content coding applied to the representation.

Content-Language

Content-Language: en
Identifies the language or languages intended for the representation.

Content-Length

Content-Length: 128
Indicates the content length in bytes when applicable to the message framing.

These headers are useful because the client needs to understand what it received and, where relevant, how to interpret or decode it.

4.4 Authentication-related headers

Authentication-related headers communicate credentials or authentication challenges.

Authorization

Authorization: Bearer
Used by a client to present credentials to the server.

WWW-Authenticate

WWW-Authenticate: Bearer realm="api"
Sent by a server to indicate an authentication scheme or challenge.

Proxy-Authorization

Proxy-Authorization: Basic
Carries credentials intended for a proxy that requires authentication.

Proxy-Authenticate

Proxy-Authenticate: Basic realm="proxy"
Used by a proxy to indicate its authentication requirements.

These fields have different roles depending on whether authentication is being performed with an origin server or a proxy.

4.5 Caching headers

Caching headers help clients and intermediary caches decide whether a response can be reused and whether it needs revalidation.

Cache-Control

Cache-Control: max-age=3600
Allows a response to be considered fresh for up to 3,600 seconds, subject to the applicable caching rules.

ETag

ETag: "v1-abc123"
Provides a validator for a particular representation.

If-None-Match

If-None-Match: "v1-abc123"
Allows a client to ask whether the representation still matches a previously received entity tag.

Last-Modified

Last-Modified: Fri, 16 Oct 2026 08:00:00 GMT
Indicates when the representation was last modified, when the server provides that information.

If-Modified-Since

If-Modified-Since: Fri, 16 Oct 2026 08:00:00 GMT
Allows a client to request a response based on whether the representation has changed since a specified time.

For example, if a cached representation is still valid, the server might return 304 Not Modified, allowing the client to reuse its cached copy instead of downloading the representation again.

4.6 Security-related headers

Security-related response headers can instruct browsers to apply certain security protections.

Strict-Transport-Security

Strict-Transport-Security: max-age=31536000
Instructs supporting browsers to use HTTPS for future requests to the relevant host for the specified duration, subject to the header's rules.

Content-Security-Policy

Content-Security-Policy: default-src 'self'
Defines restrictions on the sources from which a browser may load certain resources.

X-Content-Type-Options

X-Content-Type-Options: nosniff
Helps prevent browsers from interpreting certain responses as a different content type through MIME sniffing.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin
Controls how much referrer information the browser includes in requests.

These headers can strengthen browser-side security, but they are not substitutes for proper authentication, authorization, input validation, and secure application design.

Conclusion

HTTP communication is built around requests and responses.

A request tells the server what the client wants to do and may include headers and a body. A response communicates the outcome through a status code and may return headers and a body.

Headers provide additional information about the request or response, including content types, authentication, caching, and security policies.

Understanding these building blocks is essential for anyone working with frontend applications, backend APIs, mobile applications, or web infrastructure.

In the next part of our Deeper Dive into HTTP series, we'll explore what happens beneath these messages: how HTTP communication travels across the network, the role of TCP and UDP, connection reuse with Keep-Alive, and what changes with HTTP/3.

If you found this useful, follow AshayCodes - Instagram and YouTube for more practical explanations of the technologies we use every day.

Happy learning!

What Is HTTP? Why Is It Stateless? So how does login work? | Deeper Dive into HTTP #1

Ashay Tiwari — Thu, 15 Oct 2026 09:46:32 +0000

Have you ever wondered how your browser communicates with a backend server? Or how a website remembers that you're logged in, even though HTTP is a stateless protocol?

These questions might seem simple, but understanding them gives you a much stronger foundation for building web applications, debugging APIs, and understanding what happens behind the scenes when you interact with a website.

In this first article of the Deeper Dive into HTTP series, we'll explore three fundamental questions:

What exactly is HTTP?
Why is HTTP considered stateless?
If HTTP is stateless, how does login work?

Let's understand them quickly.

What Is HTTP?

HTTP stands for Hypertext Transfer Protocol. It is an application-layer protocol that defines how clients and servers communicate by exchanging messages.

Whenever you open a website, fetch data from an API, submit a form, or load resources for a web application, HTTP is likely involved in that communication.

Consider a typical web application:

Client: Your browser or mobile application.
Server: A backend application that processes requests and returns responses.
HTTP: The protocol that defines how those requests and responses are structured and exchanged.

For example, imagine opening a user profile page.

Your browser might send a request like this:

GET /api/users/123 HTTP/1.1
Host: example.com
Accept: application/json

This request tells the server that the client wants to retrieve information about a user.

The server might respond with:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": "123",
  "name": "Ashay"
}

Here, GET is the HTTP method, /api/users/123 is the request target, and 200 OK is the status code indicating success.

The response contains a status code, headers, and a body with the requested data.

This is the fundamental communication pattern:

Client → HTTP Request → Server → HTTP Response → Client

HTTP defines the format and structure of this exchange. It doesn't, by itself, define how your application stores users, queries a database, or implements its business logic.

The application and its infrastructure handle those responsibilities.

What Does It Mean That HTTP Is Stateless?

Let's start with a simple example.

Imagine sending the following request to a server:

GET /home HTTP/1.1
Host: example.com

The server processes the request and returns:

HTTP/1.1 200 OK
Content-Type: text/html

Now, suppose you send another request to a server:

GET /profile HTTP/1.1
Host: example.com

The server processes the request and returns:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": "123",
  "name": "Ashay"
}

From the perspective of HTTP's request semantics, the second request does not automatically carry the server's memory of the first request.

The server doesn't inherently know whether this is your first request, your tenth request, or a request made by someone who visited the website yesterday.

That's the central idea behind HTTP statelessness.

HTTP is designed so that each request can be understood independently, without requiring the server to remember the context of previous requests.

Why Was HTTP Designed This Way?

Statelessness offers several advantages.

1. Simplicity

Each request can be handled independently.

The server doesn't have to maintain the complete history of every client request just because HTTP exists.

2. Scalability

Imagine you have millions of users.

If every request depended on a particular server remembering the user's previous requests, scaling your application could become more complicated.

With stateless requests, different servers can handle different requests as long as the required state is available through other mechanisms.

3. Reliability

Because requests aren't inherently tied to one server's HTTP-level memory, the system can be designed to distribute requests across multiple servers.

But Then... How Does Login Work?

Let's say you open a website and enter:

Username: ashay
Password: ********

Your browser sends a login request:

POST /login

The server verifies your credentials.

If they're correct, the server needs some way to identify you on future requests.

One common approach is a session.

The server creates a session and gives the browser a session identifier.

That identifier can be stored in a cookie.

For example:

Session ID → abc123

Then later, when your browser requests:

GET /profile

the browser sends the cookie along with the request.

The server can use that session identifier to determine which authenticated session the request belongs to.

So the server can say:

"This request belongs to the authenticated session associated with this session ID."

And that's how it can recognize you across multiple requests.

But Wait...
Does this mean HTTP is no longer stateless?

No.

This is a very important distinction.

HTTP itself is still stateless.

We're simply using an additional mechanism, such as cookies and server-side sessions, to carry authentication state between requests.

Point to remember

HTTP is stateless.

Authentication state is managed on top of HTTP.

Understanding this distinction is an important step toward understanding web applications beyond the code we write every day.

And this is just the beginning of our Deeper Dive into HTTP series.

In the next article, we'll explore HTTP requests, responses, and headers in more detail, including what these messages actually look like and how to interpret them when working with APIs.

If you found this useful, follow AshayCodes - Instagram and YouTube for more practical explanations of the technologies we use every day.

Happy learning!

Excited to share a small new beginning! 🚀

Ashay Tiwari — Fri, 02 Oct 2026 15:16:38 +0000

Excited to share a small new beginning! 🚀

I’ve started AshayCodes, where I’ll be sharing my experiences, learnings, and practical knowledge from my journey as a Software Engineer.

My first introduction video is now live on YouTube and Instagram. 🎥

Would love to have you along for the journey!

Youtube

Instagram

Dependency Injection in JavaScript/TypeScript: Why Should a Class Create Its Own Dependencies?

Ashay Tiwari — Thu, 13 Aug 2026 07:26:41 +0000

In the previous article, we explored the Dependency Inversion Principle (DIP).

We saw how high-level business logic becomes tightly coupled when it directly creates and depends on implementation details.

We also briefly introduced another concept:

Dependency Injection (DI).

You may have heard this term many times.

You may have even used Dependency Injection without realizing it.

But instead of starting with its definition, let's start with a problem.

The Problem

Imagine we're building an order processing system.

Our OrderService needs to send an email when an order is created.

We might write:

class EmailService {
  send(to: string, message: string) {
    console.log(`Sending email to ${to}`);
  }
}

class OrderService {
  private emailService = new EmailService();

  createOrder() {
    // Create order...

    this.emailService.send(
      "customer@example.com",
      "Your order has been placed."
    );
  }
}

Looks simple.

OrderService needs an EmailService, so it creates one.

What's wrong with that?

At first, nothing.

But let's see what happens as the application grows.

The First Problem: Changing the Dependency

Suppose the application initially uses one email provider.

Later, the business decides to switch to another provider.

Our OrderService is now directly connected to the original implementation.

We have to change it.

class OrderService {
  private emailService = new NewEmailService();
}

The order logic shouldn't have to know which email service the company uses.

But because it creates the dependency itself, it has no choice.

The Bigger Problem: Testing

Now imagine we want to test OrderService.

We only want to test:

Does creating an order trigger an email?

But our test has a problem.

OrderService automatically creates a real EmailService.

So our test may end up:

Connecting to an external service.
Making unnecessary network requests.
Depending on external configuration.
Becoming slower.
Becoming harder to make deterministic.

All because OrderService decided to create its own dependency.

What If We Could Provide the Dependency?

Instead of this:

class OrderService {
  private emailService = new EmailService();
}

What if we did this?

class OrderService {
  constructor(private emailService: EmailService) {}

  createOrder() {
    // Create order...

    this.emailService.send(
      "customer@example.com",
      "Your order has been placed."
    );
  }
}

And outside the class:

const emailService = new EmailService();

const orderService = new OrderService(emailService);

Something important just happened.

OrderService no longer creates its dependency.

Someone else provides it.

That's Dependency Injection.

The Simplest Definition

Dependency Injection simply means:

A class receives the dependencies it needs from the outside instead of creating them itself.

That's it.

The dependency is injected into the object.

Why Is This Better?

Now OrderService doesn't care where the email service came from.

We can provide the real implementation:

const emailService = new EmailService();

const orderService = new OrderService(emailService);

Or a fake implementation during testing:

class FakeEmailService {
  send(to: string, message: string) {
    console.log("Fake email sent");
  }
}

Then:

const fakeEmailService = new FakeEmailService();

const orderService = new OrderService(fakeEmailService);

The OrderService doesn't need to change.

It simply receives something that provides the behavior it needs.

But There Is Still a Problem

Our previous example depends directly on EmailService.

That's better than creating it internally, but we can take it one step further.

What if we define what OrderService actually needs?

It doesn't necessarily need an EmailService.

It needs something capable of sending emails.

So we define an abstraction.

interface EmailSender {
  send(to: string, message: string): void;
}

Our actual service implements it:

class EmailService implements EmailSender {
  send(to: string, message: string) {
    console.log(`Sending email to ${to}`);
  }
}

Now OrderService depends on the abstraction.

class OrderService {
  constructor(private emailSender: EmailSender) {}

  createOrder() {
    // Create order...

    this.emailSender.send(
      "customer@example.com",
      "Your order has been placed."
    );
  }
}

This is where Dependency Injection and Dependency Inversion work nicely together.

DI and DIP Are Not the Same Thing

These terms are often used interchangeably, but they mean different things.

Dependency Inversion Principle

DIP is a design principle.

It tells us that high-level modules shouldn't be tightly coupled to low-level implementation details.

Dependency Injection

DI is a technique.

It provides a practical way to supply dependencies from outside.

You can use Dependency Injection without perfectly following DIP.

And DIP can be achieved through different techniques.

But in practice, they are often used together.

Dependency Injection in Real Applications

You've probably already used Dependency Injection.

Consider a React component.

function UserProfile({ userService }: Props) {
  // ...
}

The component doesn't create userService.

It receives it.

The same idea appears in:

Backend services
Database repositories
API clients
Logging systems
Authentication providers
Payment processors
File storage
Notification services

The pattern is always similar:

Instead of:

Class → creates dependency

We have:

Class ← receives dependency

**Does DI Always Require a Framework?

**
No.

This is another common misconception.

Dependency Injection doesn't require:

NestJS
Angular
Spring
.NET
A DI container

This is Dependency Injection:

class OrderService {
  constructor(private paymentService: PaymentService) {}
}

And:

const paymentService = new PaymentService();

const orderService = new OrderService(paymentService);

No framework.

No library.

Just JavaScript/TypeScript.

A DI framework simply automates the process of creating and connecting these dependencies.

The Composition Root

At some point, someone still has to create the objects.

We haven't eliminated object creation.

We've moved it to a better place.

For example:

const paymentService = new StripePaymentService();

const orderService = new OrderService(
  paymentService
);

This part of the application is sometimes called the composition root.

It's where we decide:

Which implementation should be used?

The business logic doesn't need to know.

This creates a useful separation:

Application Setup
       │
       ├── StripePaymentService
       └── OrderService
                │
                ↓
        PaymentProcessor

The configuration decides the implementation.

The business logic simply uses the abstraction.

The Benefits of Dependency Injection

Easier Testing

Dependencies can easily be replaced with mocks, fakes, or stubs.

Easier Maintenance

Classes don't need to know how their dependencies are created.

Lower Coupling

Business logic becomes less dependent on concrete implementations.

Greater Flexibility

Different implementations can be provided without changing the consuming class.

But Is DI Always Better?

Not necessarily.

Dependency Injection also introduces some complexity.

Compare:

const orderService = new OrderService();

with:

const orderService = new OrderService(
  paymentService,
  emailService,
  inventoryService,
  logger,
  analyticsService
);

The second approach can become difficult to understand if taken too far.

You can also end up with a codebase where every class has an interface, every dependency is injected, and simple object creation becomes unnecessarily complicated.

Again, the goal isn't to apply a principle everywhere.

The goal is to solve a real problem.

Concluding This Series — For Now 🙂

With this article, we've reached a natural stopping point for this part of the series.

We started with the fundamentals of OOP, explored its core concepts, questioned where Factory Functions fit in, and then moved into SOLID Principles and Dependency Injection.

But software design is a much bigger topic.

There are still many areas worth exploring—from Design Patterns and Inversion of Control to architecture, coupling, cohesion, and many of the practical decisions we face while building real-world software.

We'll continue exploring these topics in future articles, always following the same approach:

Don't just learn what a concept is. Understand why it exists, what problem it solves, and when it actually makes sense to use it.

For now, this is where we'll conclude this part of the journey.

See you in the next one. 🚀

Dependency Inversion Principle (DIP): Why Should High Level Module Depend on Details?

Ashay Tiwari — Wed, 12 Aug 2026 08:13:42 +0000

We've finally reached the fifth and last principle of SOLID:

Dependency Inversion Principle (DIP).

So far, we've talked about:

SRP — Keep responsibilities focused.
OCP — Extend behaviour without constantly modifying existing code.
LSP — Subtypes should be genuine substitutes for their parent types.
ISP — Don't force clients to depend on things they don't need.

DIP brings many of these ideas together.

Its formal definition says:

High-level modules should not depend on low-level modules. Both should depend on abstractions.

And the second part says:

Abstractions should not depend on details. Details should depend on abstractions.

That's technically correct.

But it's not particularly easy to understand.

So, as always, let's start with a problem.

The Problem

Imagine we're building an e-commerce application.

When an order is placed, we need to send a confirmation email.

A simple implementation might look like this:

class EmailService {
  send(to: string, message: string) {
    console.log(`Sending email to ${to}`);
  }
}

class OrderService {
  private emailService = new EmailService();

  createOrder() {
    // Create order...

    this.emailService.send(
      "customer@example.com",
      "Your order has been placed."
    );
  }
}

At first, this looks perfectly reasonable.

OrderService needs to send an email.

So it creates an EmailService.

What's wrong with that?

The Hidden Dependency

Our OrderService isn't really saying:

I need something that can send notifications.

It's saying:

I specifically need this particular EmailService.

That's an important difference.

Today, we're sending emails.

Tomorrow, the business might say:

"We also want to send a push notification."

Or:

"For some customers, send an SMS instead."

Or:

"We're moving to a different email provider."

Now OrderService is affected by all of those decisions.

Why?

Because the high-level business logic is directly connected to a low-level implementation.

What Is High-Level and Low-Level?

This terminology can sound confusing, so let's simplify it.

High-level code

This represents business decisions.

For example:

OrderService
PaymentService
CheckoutService

These answer questions like:

What should the application do?

Low-level code

This represents implementation details.

For example:

EmailService
StripePaymentService
MySQLRepository
S3Storage

These answer questions like:

How exactly should we do it?

The problem occurs when business logic becomes tightly coupled to implementation details.

Let's Look at a Payment Example

Suppose our checkout service directly uses Stripe.

class CheckoutService {
  private paymentService = new StripePaymentService();

  checkout(amount: number) {
    this.paymentService.charge(amount);
  }
}

Everything works.

Until the business says:

We're moving from Stripe to Razorpay.

Now we need to change CheckoutService.

But why should the checkout logic care which payment provider we're using?

The business requirement is:

Process the payment.

The implementation detail is:

Use Stripe.

Those are two different concerns.

The Idea Behind Dependency Inversion

Instead of making the high-level module depend directly on the implementation, we introduce an abstraction.

interface PaymentProcessor {
  charge(amount: number): void;
}

Now Stripe can implement that abstraction.

class StripePaymentProcessor implements PaymentProcessor {
  charge(amount: number) {
    console.log("Charging through Stripe...");
  }
}

And Razorpay can implement the same abstraction.

class RazorpayPaymentProcessor implements PaymentProcessor {
  charge(amount: number) {
    console.log("Charging through Razorpay...");
  }
}

Our CheckoutService no longer needs to know about either provider.

class CheckoutService {
  constructor(
    private paymentProcessor: PaymentProcessor
  ) {}

  checkout(amount: number) {
    this.paymentProcessor.charge(amount);
  }
}

Now the dependency points toward the abstraction.

What Changed?

Before:

CheckoutService
      ↓
StripePaymentProcessor

After:

CheckoutService
      ↓
PaymentProcessor
      ↑
StripePaymentProcessor

The important part isn't the arrow diagram.

It's the relationship.

CheckoutService no longer cares about Stripe.

It only cares about a capability:

Give me something that can process a payment.

The implementation can change without changing the business logic.

This Is Where Dependency Injection Comes In

You might have noticed something in our example.

We're no longer creating the payment processor inside CheckoutService.

We're receiving it from outside.

const paymentProcessor = new StripePaymentProcessor();

const checkoutService = new CheckoutService(
  paymentProcessor
);

This is Dependency Injection.

Instead of a class creating its own dependencies, those dependencies are provided to it.

DIP and Dependency Injection are closely related, but they are not the same thing.

DIP is a design principle.

Dependency Injection is one technique we can use to implement that principle.

We'll explore Dependency Injection in much more detail in the next article.

Why Is This Useful?

This design gives us several benefits.

Easier to Change

Switching payment providers doesn't require changing CheckoutService.

Easier to Test

We can provide a fake payment processor.

class FakePaymentProcessor implements PaymentProcessor {
  charge(amount: number) {
    console.log("Fake payment");
  }
}

Now we can test checkout logic without making a real payment.

Less Coupling

Business logic isn't tied to a specific technology.

Better Extensibility

Adding another implementation doesn't require modifying the high-level module.

DIP Isn't About Interfaces Everywhere

There's another common misunderstanding.

DIP doesn't mean:

Create an interface for every class.

That would quickly turn a simple application into an unnecessarily complicated one.

The real question is:

Which dependencies represent decisions or details that are likely to vary?

Those are the places where abstractions become valuable.

If something is simple, stable, and unlikely to change, introducing another abstraction may only add complexity.

The Bigger Picture

Now look at what we've covered across SOLID.

SRP tells us:

Keep responsibilities focused.

OCP tells us:

The system should be open for extension but closed for modification.

LSP tells us:

Child Entities preserve the behaviour clients expect.

ISP tells us:

Keep interfaces focused.

DIP tells us:

Don't tightly couple business logic to implementation details.

These aren't isolated rules.

They work together.

And together, they help us build scalable and maintainable software.

The Key Takeaway

Dependency Inversion isn't about avoiding dependencies.

Software will always have dependencies.

The goal is to control which direction those dependencies point.

Your business logic shouldn't have to know whether data comes from:

PostgreSQL
MongoDB
REST API
GraphQL

Or whether a payment is processed through:

Stripe
Razorpay
PayPal

Those are implementation details.

The business logic should depend on abstractions that represent what it actually needs.

What's Next?

We've now completed all five SOLID principles.

But one important concept has appeared repeatedly throughout this article:

Dependency Injection.

We've used it without fully exploring it.

So in the next article, we'll take a step back and ask a very practical question:

Why should a class create its own dependencies when someone else can provide them?

We'll explore Dependency Injection, understand the problem it solves, and see how it works in real JavaScript and TypeScript applications.

Interface Segregation Principle (ISP): Why Should a Class Implement What It Doesn't Need?

Ashay Tiwari — Tue, 11 Aug 2026 13:27:55 +0000

So far, we've explored three SOLID principles:

Single Responsibility Principle (SRP) — keep responsibilities together.
Open/Closed Principle (OCP) — make software easier to extend.
Liskov Substitution Principle (LSP) — objects of a superclass should be replaceable with objects of its subclasses

Now let's look at the fourth principle.

Interface Segregation Principle (ISP).

The formal definition says:

Clients should not be forced to depend on interfaces they do not use.

Sounds reasonable.

But what does that actually mean?

Let's start with a problem.

The Problem

Imagine we're building an application for managing employees.

Different employees can perform different actions.

Some employees can:

Work
Attend meetings
Take breaks

Some can also:

Approve expenses
Manage teams
Conduct interviews

So we create an interface:

interface Employee {
  work(): void;
  attendMeeting(): void;
  takeBreak(): void;
  approveExpenses(): void;
  conductInterview(): void;
}

Looks convenient.

Everything related to an employee is in one place.

Now let's create a regular developer.

class Developer implements Employee {
  work() {
    console.log("Writing code...");
  }

  attendMeeting() {
    console.log("Attending meeting...");
  }

  takeBreak() {
    console.log("Taking a break...");
  }

  approveExpenses() {
    // Not applicable
  }

  conductInterview() {
    // Not applicable
  }
}

We have a problem.

The developer is being forced to implement methods that don't make sense for them.

The "Not Applicable" Problem

We might try to solve this by throwing an error.

approveExpenses() {
  throw new Error("Developers cannot approve expenses.");
}

Or perhaps we leave the method empty.

approveExpenses() {}

Neither solution feels right.

Why should a Developer be required to implement something that isn't part of its responsibility?

The problem isn't with the developer.

The problem is with our interface.

We've created an interface that is trying to represent too many things at once.

The Idea Behind ISP

Instead of one large interface, we can split it into smaller, focused interfaces.

interface Worker {
  work(): void;
}

interface MeetingParticipant {
  attendMeeting(): void;
}

interface BreakTaker {
  takeBreak(): void;
}

interface ExpenseApprover {
  approveExpenses(): void;
}

interface Interviewer {
  conductInterview(): void;
}

Now a developer can implement only what they actually need.

class Developer implements Worker, MeetingParticipant, BreakTaker {
  work() {
    console.log("Writing code...");
  }

  attendMeeting() {
    console.log("Attending meeting...");
  }

  takeBreak() {
    console.log("Taking a break...");
  }
}

A manager might implement more capabilities.

class Manager
  implements Worker, MeetingParticipant, BreakTaker, ExpenseApprover, Interviewer {

  work() {}

  attendMeeting() {}

  takeBreak() {}

  approveExpenses() {}

  conductInterview() {}
}

Now our design represents reality much better.

Why Does This Matter?

At first, this might seem like a small improvement.

But imagine the application becomes much larger.

Suppose dozens of classes implement our original Employee interface.

Now we decide to add a new method:

interface Employee {
  ...
  generatePayrollReport(): void;
}

Suddenly every class implementing Employee has to deal with this new method.

Even classes that have absolutely nothing to do with payroll.

This is one of the hidden costs of large interfaces.

A change in one part of an interface can force unrelated classes to change.

That's exactly the kind of coupling ISP tries to reduce.

ISP Isn't About Creating Tiny Interfaces Everywhere

This is important.

After learning ISP, it's easy to go too far.

You might end up creating interfaces like:

interface CanCreate {}

interface CanUpdate {}

interface CanDelete {}

interface CanRead {}

And suddenly the codebase has hundreds of interfaces.

That's not the goal.

The goal isn't:

Make every interface as small as possible.

The goal is:

Don't force a client to depend on behaviour it doesn't need.

Sometimes a larger interface genuinely represents one cohesive concept.

There's nothing wrong with that.

The problem begins when unrelated responsibilities are bundled together.

A Simple Way to Think About ISP

Whenever you're designing an interface, ask:

Does every implementation actually need all of these methods?

If the answer is repeatedly "no", that's a signal that the interface may be doing too much.

Another useful question is:

If I add a new method to this interface, how many unrelated classes will I have to change?

If the answer is "a lot", you may have a fat interface.

ISP and Real-World APIs

This principle isn't limited to classes.

The same thinking applies to APIs and modules.

Imagine a service exposes:

userService.createUser()
userService.deleteUser()
userService.generateReport()
userService.sendMarketingEmail()
userService.exportFinancialData()

A component that only needs to create users shouldn't necessarily depend on everything the service can do.

Smaller, focused contracts make dependencies clearer.

This becomes especially important when we start discussing Dependency Inversion and Dependency Injection.

The Key Takeaway

The Interface Segregation Principle is essentially about avoiding unnecessary dependencies.

Instead of creating one large interface that tries to describe everything, create focused contracts around meaningful capabilities.

That way:

Classes implement only what they need.
Changes affect fewer parts of the system.
Dependencies become clearer.
Interfaces become easier to understand and maintain.

The important thing isn't the number of methods in an interface.

It's whether those methods belong together from the perspective of the clients using them.

What's Next?

We've now covered four of the five SOLID principles:

SRP — Keep responsibilities focused.
OCP — Extend behaviour without constantly modifying existing code.
LSP — Subtypes should genuinely be replaceable for their parent types.
ISP — Don't force clients to depend on things they don't need.

One principle remains.

And arguably, it's the one that connects many of the ideas we've discussed so far.

Dependency Inversion Principle (DIP).

We'll explore why high-level business logic shouldn't be tightly coupled to low-level implementation details—and how this idea eventually leads us to Dependency Injection.

Liskov Substitution Principle (LSP): Can Every Child Truly Replace Its Parent?

Ashay Tiwari — Mon, 03 Aug 2026 04:37:08 +0000

So far in this series, we've explored two of the SOLID principles.

Single Responsibility Principle (SRP) taught us to design classes with one clear responsibility.
Open/Closed Principle (OCP) showed us how to extend software without constantly modifying existing, stable code.

Now it's time to look at what is often considered the most misunderstood SOLID principle:

The Liskov Substitution Principle (LSP).

Its formal definition is:

Objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program.

That's... a mouthful.

The definition is technically correct, but it doesn't tell us why this principle exists.

So, like every article in this series, let's start with a problem.

The Problem

Imagine we're building a payment system.

Every payment method should support refunds.

So we create a base class.

abstract class PaymentMethod {
  abstract pay(amount: number): void;
  abstract refund(amount: number): void;
}

Now we implement different payment methods.

class CreditCardPayment extends PaymentMethod {
  pay(amount: number) {
    console.log("Payment successful.");
  }

  refund(amount: number) {
    console.log("Refund successful.");
  }
}

Everything works perfectly.

Later, the business introduces Cash on Delivery (COD).

Naturally, we extend the same parent class.

class CashOnDeliveryPayment extends PaymentMethod {
  pay(amount: number) {
    console.log("Customer will pay on delivery.");
  }

  refund(amount: number) {
    throw new Error("Refunds are not supported.");
  }
}

The application compiles.

The inheritance hierarchy looks correct.

But do we actually have a valid substitute for PaymentMethod?

Not really.

What goes wrong?

Somewhere else in the application, another developer writes:

function cancelOrder(payment: PaymentMethod) {
  payment.refund(500);
}

This function doesn't care whether it's dealing with:

Credit Card
UPI
PayPal

It simply assumes:

Every PaymentMethod supports refunds.

That assumption was true...

Until CashOnDeliveryPayment appeared.

Now the application crashes.

The problem isn't the function.

The problem is that one child class broke the expectations established by its parent.

The Real Meaning of LSP

Liskov Substitution Principle asks a simple question:

If I replace a parent object with one of its children, should the rest of the program continue to work correctly?

If the answer is no, the inheritance relationship is probably incorrect.

The child isn't truly behaving like the parent promised.

Another Famous Example

Perhaps you've seen this example before.

Imagine we model shapes like this.

Shape
├── Rectangle
└── Square

It sounds perfectly reasonable.

After all...

A square is a rectangle.

Right?

Let's see.

A rectangle allows width and height to change independently.

rectangle.setWidth(10);
rectangle.setHeight(5);

Now imagine Square.

Whenever we change the width, we must also change the height.

square.setWidth(10);

// Height automatically becomes 10

Now consider this function.

function resizeRectangle(rectangle: Rectangle) {
  rectangle.setWidth(10);
  rectangle.setHeight(5);

  console.log(rectangle.getArea());
}

If we pass a normal rectangle...

Area = 50

If we pass a square...

Area = 100

The function behaves differently because the child changed the expectations established by the parent.

The inheritance relationship looked correct mathematically.

It wasn't correct from a software design perspective.

The Root Problem

The issue isn't inheritance.

The issue is a bad abstraction.

Inheritance creates expectations.

Whenever we inherit from a parent class, we're making a promise.

We're saying:

You can use me anywhere you use my parent.

If that promise isn't true...

Inheritance becomes dangerous.

Other developers begin making assumptions - that aren't always valid.

Those assumptions eventually become bugs.

LSP Is About Behaviour, Not Hierarchy

One of the biggest misconceptions is thinking LSP is about inheritance syntax.

It isn't.

The compiler only checks whether a child inherits correctly.

LSP asks something deeper.

Does the child preserve the behaviour clients expect?

Two classes may have identical methods.

They may even share the same parent.

Yet one may still violate LSP if it behaves differently in unexpected ways.

Behaviour matters more than hierarchy.

How to Spot an LSP Violation

Here are a few warning signs.

A child throws UnsupportedOperationException or similar errors for inherited methods.
A child ignores methods defined by the parent.
Client code starts checking object types before calling methods.

For example:

if (payment instanceof CashOnDeliveryPayment) {
  // Skip refund
}

Whenever you find yourself writing lots of instanceof checks for subclasses, it's often a sign that the inheritance hierarchy isn't modelling the problem correctly.

A Better Design

Instead of forcing every payment method to support refunds, separate the capabilities.

interface PaymentMethod {
  pay(amount: number): void;
}

interface Refundable {
  refund(amount: number): void;
}

Now:

Credit Card implements both.
PayPal implements both.
Cash on Delivery only implements PaymentMethod.

No fake implementations.

No unexpected exceptions.

No broken promises.

The Key Takeaway

The Liskov Substitution Principle teaches us that inheritance isn't just about sharing code.

It's about preserving expectations.

Whenever a child class replaces its parent, the rest of the application should continue to work without knowing the difference.

If client code needs special cases for certain subclasses, or if some subclasses can't persist the behaviour promised by the parent, the inheritance hierarchy probably needs another look.

What's Next?

We've now covered three SOLID principles.

SRP helped us design focused classes.
OCP taught us to extend behaviour without modifying stable code.
LSP reminded us that inheritance should preserve behaviour, not just structure.

Next, we'll explore the Interface Segregation Principle (ISP).

We'll answer another practical question:

Why is forcing classes to implement methods they don't need considered a design problem?

Open/Closed Principle (OCP): How Do We Add Features Without Breaking Existing Code?

Ashay Tiwari — Wed, 29 Jul 2026 07:26:39 +0000

In the previous article, we discussed the Single Responsibility Principle (SRP) and learned that a class should have one clear reason to change.

Now let's look at the second SOLID principle:

Open/Closed Principle (OCP).

This principle is often summarized as:

Software entities should be open for extension but closed for modification.

It's a famous definition.

It's also one of the most misunderstood.

The obvious question is:

How can something be open and closed at the same time?

Let's start with the problem.

The Problem

Imagine you're building an e-commerce application.

Initially, the business only supports two payment methods:

Credit Card
UPI

Your implementation might look like this:

function processPayment(type: string, amount: number) {
  if (type === "credit-card") {
    console.log("Processing credit card payment...");
  } else if (type === "upi") {
    console.log("Processing UPI payment...");
  }
}

Everything works.

A month later, the business wants to support PayPal.

So we modify the function.

if (type === "paypal") {
  ...
}

A few weeks later:

Apple Pay
Bank Transfer
Gift Cards

Every new payment method requires editing the same function.

Again.

And again.

What's the Real Problem?

At first glance, modifying the function doesn't seem like a problem.

After all, adding new functionality usually means changing code.

But consider this.

That payment function is already:

Tested.
Used by multiple parts of the application.
Running successfully in production.

Every modification introduces risk.

A small mistake while adding Apple Pay could accidentally break UPI payments.

The more frequently we modify stable code, the greater the chance of introducing bugs.

The problem isn't adding new features.

The problem is having to modify existing, working code every time a new requirement appears.

The Idea Behind OCP

The Open/Closed Principle encourages us to design software so that new behaviour can be added without modifying existing, tested code.

Notice the wording.

It doesn't say:

Never modify code.

That's unrealistic.

Instead, it asks:

Can we design our code so new features are added by extending it rather than editing it?

That's a subtle but powerful shift in thinking.

Question

If you were designing this using what you've already learned about:

Abstraction
Interfaces
Polymorphism

How would you avoid the growing chain of:

function processPayment(type: string, amount: number) {
  if (type === "credit-card") {
    console.log("Processing credit card payment...");
  } else if (type === "upi") {
    console.log("Processing UPI payment...");
  }
}

A Better Approach

Instead of one function knowing about every payment method, each payment method can be responsible for processing itself.

Applying Polymorphism

interface PaymentMethod {
  process(amount: number): void;
}

Now we create separate implementations.

class CreditCardPayment implements PaymentMethod {
  process(amount: number) {
    console.log("Processing credit card payment...");
  }
}

class UpiPayment implements PaymentMethod {
  process(amount: number) {
    console.log("Processing UPI payment...");
  }
}

The checkout process no longer needs to know which payment method it's dealing with.

function checkout(payment: PaymentMethod, amount: number) {
  payment.process(amount);
}

Now suppose the business wants to support PayPal.

Do we modify checkout()?

No.

We simply create another implementation.

class PayPalPayment implements PaymentMethod {
  process(amount: number) {
    console.log("Processing PayPal payment...");
  }
}

The existing checkout logic remains untouched.

We've extended the system without modifying stable code.

That's exactly what OCP is encouraging.

What Changed?

Previously:

DiscountService
   ↓
knows all discount types

Now:

DiscountService
   ↓
knows only DiscountStrategy

That's abstraction.

Why Is This Useful?

Following OCP provides several benefits.

Less Risk
Existing, tested code remains unchanged.
Easier Feature Development
New functionality is added instead of squeezed into existing logic.
Better Team Collaboration
Different developers can work on new features without constantly editing the same files.
Improved Maintainability
The system naturally grows by adding new pieces instead of making one central component increasingly complex.

Does OCP Mean Never Modify Existing Code?

Not at all.

This is probably the biggest misconception.

Sometimes modifying existing code is absolutely the right thing to do.

If you discover:

A bug
Poor design
Duplicate logic
Performance issues

You should improve it.

OCP isn't about avoiding modifications at all costs.

It's about designing systems where expected future changes are handled through extension rather than repeatedly editing the same code.

The Trade-offs

Like every design principle, OCP isn't free.

Supporting extension often means:

More interfaces.
More abstractions.
More classes.

If your application is small or unlikely to change, these extra layers may provide little value.

The goal isn't to predict every future requirement.

It's to recognise areas of the system that are likely to evolve and design those areas thoughtfully.

What's Next?

We've now explored two SOLID principles.

SRP taught us to give each class one clear responsibility.

OCP taught us how to extend behaviour without repeatedly modifying stable code.

Next, we'll tackle one of the most debated principles in software design:

The Liskov Substitution Principle (LSP).

We'll answer an interesting question:

Just because one class inherits from another, does it really mean it can replace it?

Single Responsibility Principle (SRP): How Much Responsibility Should a Class Really Have?

Ashay Tiwari — Mon, 27 Jul 2026 06:59:08 +0000

In the previous article, we discussed why Object-Oriented Programming alone wasn't enough and how the SOLID principles emerged to help developers design more maintainable software.

Today, we'll explore the first principle:

Single Responsibility Principle (SRP).

Many developers hear:

A class should have only one responsibility.

Then immediately wonder:

Does that mean a class should have only one method?

Or:

Should every class do just one tiny thing?

Not quite.

Let's understand the problem SRP was trying to solve.

The Problem

Imagine we're building an e-commerce application.

We create an OrderService.

Initially, its job is simple.

OrderService

✓ Create Order

Everything looks fine.

As the application grows, new requirements arrive.

"We need to calculate discounts."

No problem.

OrderService

✓ Create Order
✓ Calculate Discount

A week later:

"We should send a confirmation email."

OrderService

✓ Create Order
✓ Calculate Discount
✓ Send Email

A month later:

"We also need to generate invoices."

OrderService

✓ Create Order
✓ Calculate Discount
✓ Send Email
✓ Generate Invoice

Then someone asks for audit logs.

Inventory updates.

Loyalty points.

Analytics.

Before long, the class looks like this:

OrderService

✓ Create Order
✓ Calculate Discount
✓ Process Payment
✓ Update Inventory
✓ Generate Invoice
✓ Send Email
✓ Record Analytics
✓ Write Audit Logs

The application still works.

But something feels wrong.

What's the Real Problem?

The issue isn't the number of methods.

The issue is that the class is trying to solve too many different problems.

Think about who might request changes.

The finance team may ask for invoice changes.

The marketing team may introduce a new discount strategy.

Operations may change inventory rules.

Customer support may request a different email template.

Analytics may require new tracking events.

Every team has a different reason to modify the same class.

Now imagine multiple developers working on it simultaneously.

Merge conflicts become common.

Testing becomes more difficult.

A small change in one area can accidentally affect another.

The class has become a bottleneck.

The Idea Behind SRP

This is where the Single Responsibility Principle comes in.

It says:

A class should have one, and only one, reason to change.

Notice something important.

It doesn't say:

One method.

It doesn't say:

One line of code.

It says:

One reason to change.

A responsibility isn't defined by the amount of code.

It's defined by the purpose the class serves.

Breaking Responsibilities Apart

Instead of putting everything into one class, we separate concerns.

OrderService
    │
    ├── DiscountService
    ├── PaymentService
    ├── InventoryService
    ├── EmailService
    ├── InvoiceService
    └── AnalyticsService

Now each class has a clear responsibility.

If invoice generation changes, we modify InvoiceService.

If email templates change, we modify EmailService.

If discount rules change, we modify DiscountService.

Each class evolves independently.

Another Real-World Example

Think about a restaurant.

One person could:

Take orders.
Cook food.
Wash dishes.
Manage inventory.
Handle payments.
Clean tables.

Technically, it's possible.

But would it be efficient?

Probably not.

Restaurants divide responsibilities because specialization makes the system easier to manage.

Software is no different.

What SRP Doesn't Mean

SRP is often misunderstood.

It doesn't mean:

❌ Every class should contain only one method.

❌ Every file should be tiny.

❌ Every function deserves its own class.

Those interpretations usually lead to unnecessary complexity.

Instead, ask yourself:

Does this class represent one clear responsibility?

If the answer is yes, you're likely on the right track.

Benefits of SRP

Following SRP makes software easier to:

Understand
Test
Maintain
Extend

It also reduces the chances that unrelated changes will accidentally affect each other.

Are There Trade-offs?

Absolutely.

Like every design principle, SRP can be overused.

If every tiny operation becomes its own class, you'll end up with hundreds of small classes that are difficult to navigate.

Good software design is about balance.

Split responsibilities when they truly represent different reasons to change.

Don't split code simply because you can.

What's Next?

We've learned how to design classes with focused responsibilities.

But another challenge still remains.

What happens when a new feature requires changing an existing, well-tested class?

Should we keep modifying it?

Or is there a better way?

In the next article, we'll explore the Open/Closed Principle (OCP) and learn why software should be open for extension but closed for modification.

Why OOP Wasn't Enough: The Problems That Led to SOLID

Ashay Tiwari — Fri, 24 Jul 2026 06:01:52 +0000

Over the last few articles, we've explored the core concepts of Object-Oriented Programming.

We discussed why OOP was introduced, how objects help us organize code, and how concepts like Encapsulation, Abstraction, Inheritance, Composition, and Polymorphism make software easier to build and maintain.

At this point, it might seem like we've found the perfect solution.

So why did developers feel the need to introduce another set of principles called SOLID?

Wasn't OOP enough?

The short answer is:

OOP gave us powerful tools, but it didn't tell us how to use them well.

Let's understand why.

The Early Days of OOP

When Object-Oriented Programming became popular, developers finally had a better way to organize software.

Instead of scattering related data and functions across an application, they could model real-world entities as objects.

It was a huge improvement.

Applications became easier to understand.

Code became more reusable.

Responsibilities felt more organized.

For a while, everything seemed to be moving in the right direction.

Then Applications Started Growing

As software evolved, projects became much larger than anyone had imagined.

Applications that once had a few dozen classes now had hundreds.

Large enterprise systems contained thousands of classes maintained by multiple teams.

And a new kind of problem started appearing.

The problem was no longer:

How do we organize code?

The problem became:

How do we organize large codebases?

Simply using classes and objects wasn't enough anymore.

OOP Doesn't Prevent Bad Design

Let's imagine we're building an e-commerce application.

We create a class called Order.

At first, it seems reasonable.

It stores order details.

Then we add price calculations.

Later, invoice generation.

Then payment processing.

Email notifications.

Inventory updates.

Discount calculations.

Audit logging.

Before we realize it, our class looks something like this:

Order
├── calculateTotal()
├── processPayment()
├── sendConfirmationEmail()
├── generateInvoice()
├── updateInventory()
├── applyDiscount()
├── writeAuditLog()
├── exportPDF()
└── ...

Technically, it's Object-Oriented.

It uses a class.

It encapsulates data.

But is it well-designed?

Probably not.

The class has become responsible for almost every part of the order lifecycle.

Changing one feature increases the risk of breaking another.

Testing becomes harder.

Understanding the class becomes harder.

Maintaining it becomes harder.

The problem wasn't OOP.

The problem was how we were using OOP.

Classes Became Too Dependent on Each Other

Another issue appeared.

Imagine a payment service.

OrderService
    │
    ▼
StripePaymentService

The OrderService creates and depends directly on StripePaymentService.

Everything works.

Until the business says:

"We're moving to Razorpay."

Now changes are needed in multiple places.

The higher-level business logic is tightly coupled to a specific implementation.

Again...

OOP didn't prevent this.

It allowed it.

Reusing Code Sometimes Made Things Worse

Inheritance was introduced to reduce duplication.

But many applications started building deep inheritance hierarchies.

Employee
    │
    ├── Manager
    │      ├── RegionalManager
    │      │       └── SeniorRegionalManager

Initially, it looked elegant.

Over time, it became difficult to understand.

A change in a parent class unexpectedly affected several child classes.

Developers realized that simply because something can inherit doesn't always mean it should.

This realization eventually led to the idea:

Favor Composition Over Inheritance.

The Missing Piece

At this point, developers had all the building blocks.

They had:

Classes
Objects
Encapsulation
Abstraction
Inheritance
Polymorphism

But something was still missing.

There were no clear guidelines for questions like:

How many responsibilities should a class have?
When should existing code be modified?
How should dependencies be managed?
How should objects communicate?
How do we build software that's easy to extend?

OOP answered:

What tools do we have?

Developers now needed answers to:

How should we use those tools?

🏋️ Enter SOLID

This is where the SOLID principles come in.

SOLID isn't a replacement for Object-Oriented Programming.

It builds on top of it.

Think of it this way.

OOP gives you the bricks, cement, and steel to construct a building.

SOLID gives you architectural guidelines for using those materials wisely.

Without those guidelines, you can still build a structure.

It just might not be easy to maintain.

What SOLID Tries to Achieve

The SOLID principles encourage us to build software that is:

Easier to understand.
Easier to modify.
Easier to test.
Easier to extend.
Less tightly coupled.
More maintainable over time.

None of these principles are magical rules.

They're lessons learned from years of building—and maintaining—large software systems.

Most of them were born from mistakes developers repeatedly encountered in real-world projects.

The Key Takeaway

Object-Oriented Programming solved many problems.

It gave developers a better way to organize software.

But it couldn't guarantee good design.

You can write terrible Object-Oriented code.

You can also write excellent Object-Oriented code.

The difference isn't the programming paradigm.

It's the design decisions you make.

That's exactly what the SOLID principles try to improve.

They don't teach us how to write Object-Oriented code.

They teach us how to write better Object-Oriented code.

What's Next?

Now that we understand why SOLID was introduced, we can finally explore the first principle:

The Single Responsibility Principle (SRP).

We'll answer a deceptively simple question:

How many responsibilities should a class really have?

As you'll see, the answer isn't "one method" or "one task."

It's much more interesting than that.

Polymorphism in OOP: One Interface, Multiple Implementations

Ashay Tiwari — Tue, 30 Jun 2026 05:40:47 +0000

Most developers memorize:

"One interface, many forms."

Unfortunately, that definition is so abstract that it doesn't teach much.

Let's understand the actual problem polymorphism solves.

🤯 The Problem

Suppose you're building a payment system.

Without polymorphism:

class PaymentService {

  processPayment(
    type: string,
    amount: number
  ) {
    if (type === 'credit-card') {
      // credit card logic
    }

    if (type === 'paypal') {
      // paypal logic
    }

    if (type === 'upi') {
      // upi logic
    }
  }
}

Works.

Then the business says:

Add Stripe

You modify:

if (type==='stripe') {}

Next month:

Add Apple Pay

Modify again.

Add Crypto

Modify again.

The class keeps growing.

This violates a key design principle:

Existing code should not need constant modification when new behavior is added.

✨ Polymorphism's Solution

Instead of asking:

What type are you?

ask:

Can you perform this action?

That's a huge mindset shift.

Example

Create a contract:

interface PaymentProvider {
  process(amount:number):void;
}

Implementations:

class CreditCardPayment implements PaymentProvider {

  process(amount: number) {
    console.log('Credit Card');
  }
}

class UpiPayment implements PaymentProvider {

  process(amount: number) {
    console.log('UPI');
  }
}

Now:

function checkout(
  provider: PaymentProvider,
  amount: number
) {
  provider.process(amount);
}

Usage:

checkout(new CreditCardPayment(),100);

checkout(new UpiPayment(),100);

checkout(new PaypalPayment(),100);

Same method call:

provider.process()

Different behavior.

This is polymorphism.

🧠 The Core Idea

Polymorphism means:

Treat different objects uniformly while allowing each object to behave differently.

You don't care:

Credit Card
UPI
PayPal

You only care:

Can you process a payment?

Real World Example

Think about a power socket.

You plug in:

Laptop charger
Phone charger
Fan
TV

The socket doesn't ask:

Are you a Samsung charger?
Are you a Dell charger?

It only expects:

Can you accept electricity?

Each device behaves differently after receiving power.

That is polymorphism.

Why Interfaces Matter

Consider:

interface UserRepository {
  findById(id:string):Promise<User>;
}

Implementation 1:

class PostgresUserRepository implements UserRepository {}

Implementation 2:

class MongoUserRepository implements UserRepository {}

Implementation 3:

class InMemoryUserRepository implements UserRepository {}

UserService:

class UserService {
  constructor(
   privaterepo: UserRepository
  ) {}
}

Notice:

repo.findById()

works regardless of:

Postgres
Mongo
Memory

The service doesn't care.

That's polymorphism.

🔑 The Key Takeaway

Polymorphism is often described as:

"One interface, many forms."

A more practical way to think about it is:

Different objects can respond to the same request in their own way.

The caller doesn't need to know the implementation.

It only needs to know the capability the object provides.

This makes systems easier to extend without constantly modifying existing code.

⏭️ What's Next?

With this article, we've completed the four core pillars commonly associated with Object-Oriented Programming:

Encapsulation
Abstraction
Inheritance
Polymorphism

But understanding these concepts doesn't automatically lead to well-designed software.

Developers soon realized that even OOP applications could become difficult to maintain if responsibilities weren't clearly defined.

That realization gave rise to a new set of guidelines known as the SOLID Principles.

In the next article, we'll explore why SOLID was introduced and the problems it was designed to solve.