DEV Community: Harsh Mangalam

UPI at Scale: Handling Millions of Payments

Harsh Mangalam — Thu, 13 Aug 2026 06:18:12 +0000

Imagine this:

It's salary day.

It's 2 PM.

Millions of people across India suddenly open their UPI apps and start paying rent, sending money to family, paying credit-card bills, and shopping online.

Now here's the system-design interview question:

If millions of people make payments at almost exactly the same time, is every request hitting one central server? What prevents the entire payment system from freezing?

At first glance, it sounds like a scaling problem.

It isn't just a scaling problem.

It's a combination of:

horizontal scaling
concurrency
distributed systems
database consistency
retries
idempotency
backpressure
failure isolation
downstream bottlenecks

And that's what makes payment systems such an interesting system-design problem.

First: Don't Imagine One Giant UPI Server

A common mental model looks like this:

             Millions of users
                    |
                    v
             +-------------+
             | UPI Server  |
             +-------------+
                    |
                    v
                  Bank

If that were literally true, we'd have a pretty serious problem.

One machine cannot safely process the country's entire payment traffic.

Instead, think about a distributed system:

                    Users
                      |
                      v
              +---------------+
              | API / Gateway |
              +---------------+
                 /    |    \
                /     |     \
               v      v      v
             [S1]   [S2]   [S3]
               |      |      |
               +------+------+
                      |
                Payment Services
                      |
             +--------+--------+
             |                 |
          Bank A             Bank B

The exact implementation of a real payment network is much more complicated than this diagram, but this is the right system-design mental model.

The important idea is:

The system is distributed across many machines and participating institutions.

Step 1: The First Problem — Traffic Spikes

Let's take a concrete example.

You want to pay your landlord:

₹25,000

At the same moment, millions of other people are doing something similar.

Suddenly:

Normal traffic:

100K requests/sec


Salary day:

████████████████████████
1M+ requests/sec

The first question is:

How do we handle the additional traffic?

Naive Solution: One Powerful Server

We could buy a massive machine.

              1M requests/sec
                     |
                     v
             +---------------+
             | HUGE SERVER   |
             | 256 CPU cores |
             | 2 TB RAM      |
             +---------------+

This is called vertical scaling.

Make the machine bigger.

But there are limits.

Eventually:

CPU        → limit
Memory     → limit
Network    → limit
Connections → limit

And there's an even bigger problem.

If the server dies:

              💥
               |
               v
        +-------------+
        | One Server  |
        +-------------+

               |
               v

          Entire system
             DOWN

For a payment system, that's unacceptable.

Solution: Horizontal Scaling

Instead of making one machine enormous, add more machines.

                    Requests
                       |
                       v
               +---------------+
               | Load Balancer |
               +---------------+
                 /     |     \
                /      |      \
               v       v       v
             [S1]    [S2]    [S3]
               |       |       |
             [S4]    [S5]    [S6]
               |       |       |
              ...     ...     ...

If one server handles 20,000 requests/sec, and we need roughly 1 million:

1,000,000 / 20,000 ≈ 50 servers

We can scale the application tier horizontally.

Now if one server fails:

S1 💥

S2
S3
S4
S5
...

Traffic can be routed to healthy servers.

This gives us our first reusable system-design pattern:

Pattern #1: Horizontal Scaling

When request volume exceeds the capacity of one machine, distribute requests across many machines.

But We've Created a New Problem

Suppose two of your payments arrive simultaneously.

Payment A:
Harsh → Landlord ₹25,000

Payment B:
Harsh → Amazon ₹20,000

They might land on different servers:

                  Load Balancer
                   /          \
                  v            v
                [S1]          [S2]
                  |             |
                  +------?------+
                         |
                       Bank

Suppose Harsh has:

₹30,000

Both servers read the balance at approximately the same time.

Server 1 sees:

₹30,000

Server 2 sees:

₹30,000

Then:

S1:
₹30,000 - ₹25,000
= ₹5,000

S2:
₹30,000 - ₹20,000
= ₹10,000

The system has effectively allowed:

₹45,000

to be spent from an account containing:

₹30,000

That's a race condition.

And this is where payment-system design gets interesting.

Step 2: We Need Atomic State Changes

A payment isn't just:

UPDATE balance

Conceptually, we need something closer to:

Check balance
     ↓
Verify payment
     ↓
Debit sender
     ↓
Credit receiver
     ↓
Record transaction

The critical state transition must happen safely under concurrency.

We need a guarantee that two competing operations cannot both incorrectly modify the same financial state.

Depending on the architecture, this can involve:

database transactions
locking
optimistic concurrency control
serialization
partition ownership
carefully designed state machines

The important interview lesson isn't:

"Use database locks."

It's:

Identify the shared mutable state and protect the critical transition.

Step 3: Now the Database Becomes the Bottleneck

Let's say we've successfully scaled our application servers.

We now have:

                    Load Balancer
                         |
          +--------------+--------------+
          |              |              |
         S1             S2             S3
          |              |              |
          +--------------+--------------+
                         |
                         v
                   +-----------+
                   | Database  |
                   +-----------+

We have 500 application servers.

But one database.

Now all those servers are fighting for the same resource.

500 servers
     |
     |
     v
+-----------+
|    DB     |
|     💥    |
+-----------+

The application tier scales.

The database doesn't.

This is a classic distributed-systems bottleneck:

The fastest part of your system doesn't matter if a slower shared dependency limits the entire system.

Step 4: Partition the Work

Instead of forcing everything through one database/resource, we can partition data and workload.

Conceptually:

                 Payment Requests
                        |
                +-------+-------+
                |               |
                v               v
           Partition A     Partition B
                |               |
              DB-A            DB-B

The partitioning strategy could be based on something like:

account ID
bank
customer ID
transaction domain
geographical region

The exact choice depends on the system.

This is generally called:

Sharding / Partitioning

The reusable pattern is:

Pattern #2: Partition the bottleneck

When one resource can't handle the workload, divide the workload into independent partitions.

But There's Another Problem

Imagine our application servers are perfectly healthy.

Our databases are perfectly healthy.

But a downstream bank suddenly becomes overloaded.

                 Payment Services
                /       |       \
               v        v        v
             Bank A   Bank B   Bank C
                                |
                                v
                              💥

Our system can process millions of incoming requests.

But the downstream dependency might only safely process a smaller amount.

This gives us another fundamental principle:

The capacity of a distributed system is constrained by its critical bottlenecks and dependencies.

You can't solve a downstream bottleneck by simply adding more application servers.

Step 5: Backpressure

Suppose a component can safely process:

100K operations/sec

but we're receiving:

300K operations/sec

If we blindly forward everything:

300K
 |
 v
[Processor]
 |
 💥

Instead, for work that is safe to process asynchronously, we can introduce a buffer:

300K requests
      |
      v
  +-------+
  | Queue |
  +-------+
      |
      | 100K/sec
      v
  +-----------+
  | Processor |
  +-----------+

The queue absorbs temporary bursts.

This gives us:

Pattern #3: Backpressure

When producers can generate work faster than consumers can process it, slow down producers or buffer the work.

This is where technologies such as Kafka or other messaging systems become useful.

But notice the reasoning.

We didn't start with:

"Let's use Kafka."

We started with:

"Our producer is faster than our consumer. We need buffering/backpressure."

Then we choose a technology.

Can We Queue the Entire Payment?

Not necessarily.

This is an important interview trap.

You shouldn't say:

"We'll just put every payment into Kafka."

Financial transactions have correctness and latency requirements.

There is a difference between:

Critical payment state transition

and:

Side effects

For example:

Payment
  |
  +----> Update financial state
  |
  +----> Send notification
  |
  +----> Update analytics
  |
  +----> Generate receipt
  |
  +----> Update recommendation system

The financial state transition may require strict correctness.

But sending:

"₹25,000 paid successfully"

to a notification service doesn't necessarily need to block the core transaction.

Those side effects can often be asynchronous.

Step 6: Now Imagine the Network Fails

Here's where payment systems become really interesting.

You press:

PAY ₹25,000

The request reaches the payment system.

The money gets debited.

But before the response reaches your phone:

Bank → 💥 network timeout 💥 → Phone

Your app says:

Payment failed

You think:

"Okay, I'll try again."

So you press Pay again.

Now the system receives:

Payment #1
₹25,000

Payment #2
₹25,000

If the system treats both as new payments:

Your account
   |
   +-- ₹25,000
   |
   +-- ₹25,000
   |
   v
₹50,000 debited

That's obviously unacceptable.

Step 7: Idempotency

We need the system to recognize:

"This retry is actually the same payment."

So the client/request can carry a unique identifier:

payment_id = ABC123

First request:

ABC123 → process payment

Retry:

ABC123 → already processed

The system returns the previous result rather than charging the user again.

Conceptually:

Request
   |
   v
+----------------------+
| payment_id = ABC123  |
+----------------------+
          |
          v
    Already exists?
       /       \
     YES        NO
      |          |
      v          v
Return result  Process

This is idempotency.

And it is one of the most important concepts in distributed systems.

Pattern #4: Idempotency

A retry of the same logical operation should not produce an additional side effect.

You will see this pattern everywhere:

payments
order creation
payment webhooks
message processing
API retries
distributed jobs

Step 8: Why Retries Are Dangerous

Retries sound harmless:

Request failed
      ↓
Retry
      ↓
Retry
      ↓
Retry

But imagine 1 million clients doing this.

              1M requests
                   |
                failure
                   |
             +-----+-----+
             |           |
           retry       retry
             |           |
             +-----+-----+
                   |
                 retry
                   |
                   v
               💥💥💥

A failing system can actually make itself more overloaded through retries.

This is called a retry storm.

So production systems need things like:

exponential backoff
jitter
retry limits
timeouts
circuit breakers
idempotency

Again, each mechanism exists because a specific failure mode exists.

The Bigger Picture

At this point our system is evolving.

We started with:

User
 |
 v
Server
 |
 v
Bank

And progressively discovered problems.

Traffic spike

                Load Balancer
               /     |      \
             S1      S2      S3

Shared state

Multiple servers
      |
      v
Concurrency control

Database bottleneck

      |
  partition
   /      \
 DB-A    DB-B

Downstream overload

Producer
   |
 Queue / Backpressure
   |
Consumer

Network failure

Request
   |
 timeout
   |
 retry

Retry duplication

payment_id
     |
idempotency

Our architecture is now becoming:

                         Users
                           |
                           v
                    +-------------+
                    |   Gateway   |
                    +-------------+
                           |
                    Load balancing
                           |
             +-------------+-------------+
             |             |             |
            S1            S2            S3
             |             |             |
             +-------------+-------------+
                           |
                    Payment Service
                           |
                    +------+------+
                    |             |
               Partition A   Partition B
                    |             |
                   DB-A          DB-B
                    |
             Critical transaction
                    |
              +-----+------+
              |            |
          Async work    Notifications
              |
            Queue

And around the entire system:

timeouts
retries
idempotency
rate limits
backpressure
monitoring
failure isolation

The Most Important Lesson

When you're asked:

"Design a UPI-scale payment system."

Don't start drawing 20 boxes.

Start asking:

1. What's the workload?

Requests/sec?
Peak requests/sec?
Average transaction size?
Read/write ratio?

2. What's the critical state?

Account balance
Transaction status
Payment ID

3. Where is concurrency dangerous?

Two payments touching the same account

4. What's the bottleneck?

Application?
Database?
Network?
Downstream bank?

5. What happens during failure?

Timeout
Crash
Duplicate request
Partial success
Network partition

6. What happens when traffic suddenly increases?

Scale
Buffer
Rate limit
Backpressure

7. What happens when the client retries?

Idempotency

This is the real system-design thought process.

A Reusable Pattern Library

By solving this one problem, we've already learned several patterns.

Problem	Pattern
One server can't handle traffic	Horizontal scaling
Shared state modified concurrently	Atomicity / concurrency control
One DB becomes bottleneck	Sharding / partitioning
Producer faster than consumer	Queue / backpressure
Request repeated after timeout	Idempotency
Dependency becomes slow/unavailable	Timeout / circuit breaker
Huge traffic spike	Rate limiting / load shedding
Temporary downstream failure	Retry + backoff

And this is exactly how you should prepare for SDE-2 system design.

Don't memorize architectures.

Memorize the problem → failure → pattern relationship.

One Final Mental Model

When you see:

"Millions of requests arrive simultaneously."

Think:

                 HUGE TRAFFIC
                      |
                      v
              Can one machine?
                   /     \
                 NO       YES
                 |
                 v
        Horizontal scaling
                 |
                 v
        What's shared?
                 |
                 v
        Concurrency problem?
                 |
                 v
        Protect state transition
                 |
                 v
        What's the bottleneck?
                 |
                 v
        Partition / scale
                 |
                 v
       What if dependency slows?
                 |
                 v
        Backpressure / queue
                 |
                 v
       What if request retries?
                 |
                 v
             Idempotency
                 |
                 v
          What if it fails?
                 |
                 v
       Timeout / retry / recovery

That's the mental model I'd want an SDE-2 candidate to have.

The interesting part of this problem isn't "How does UPI handle 1,000+ crore transactions?"

It's:

How do you build a distributed system where massive concurrency, partial failures, retries, and bottlenecks don't turn a single ₹25,000 payment into a financial disaster?

And once you understand that, you can reuse the same reasoning for Cloudflare rate limiting, ticket booking, food delivery, Uber, payment gateways, distributed job systems, and almost every large-scale backend system.

What Really Happens When 25 Lakh People Click “Book” at the Same Time?

Harsh Mangalam — Wed, 12 Aug 2026 06:17:47 +0000

Imagine this.

Tatkal booking opens at 10:00 AM.

At exactly 10:00:00, around 25 lakh people click the Book Now button.

There are only 4 seats left in your coach.

So the obvious question is:

How does the system decide which 4 people get the seats?

Is it literally first-come-first-served at the millisecond level?

And what happens to the other 24,99,996 requests?

This is a great system design problem because it teaches several important concepts at once:

load balancing
rate limiting
stateless services
race conditions
atomic operations
queues
hot keys
partitioning
backpressure
source of truth

Let’s build the system slowly, one problem at a time.

First, forget the database

A beginner might imagine the system like this:

25 lakh users
      |
      v
   Database

That would be a disaster.

A real system usually has several layers:

User
  |
  v
Internet
  |
  v
Edge / CDN / WAF
  |
  v
Load Balancer
  |
  v
API Servers
  |
  v
Booking Service
  |
  v
Inventory Service
  |
  v
Database

Each layer exists because the simpler design eventually breaks.

Let’s understand why.

1. Who actually clicked first?

Suppose two users click:

User A clicks at 10:00:00.001
User B clicks at 10:00:00.009

It looks like User A should win.

But now include network latency.

User A network latency = 100 ms
User B network latency = 20 ms

Their requests reach the booking system at:

User A → 10:00:00.101
User B → 10:00:00.029

User B reaches the server first.

So:

The system usually cannot guarantee ordering based on the exact physical moment someone clicked.

The user's laptop is outside the system's control.

Why not send the click timestamp?

You might think the browser could send:

{
  "clicked_at": "10:00:00.001"
}

But clients cannot be trusted.

A modified browser could simply send:

{
  "clicked_at": "09:59:59.000"
}

So authoritative decisions should happen on the server.

This is a useful rule far beyond ticket booking:

Never trust the client for critical state.

Examples include:

Price
Permissions
Wallet balance
Inventory
Seat availability
Booking status

2. The first problem is not seats

Before worrying about the 4 seats, there is a more immediate problem:

25 lakh requests just arrived.

If all of them enter your backend, your servers may collapse before anyone gets a ticket.

So the first layer protects the system.

25 lakh users
      |
      v
+----------------------+
| Edge / Cloudflare    |
|----------------------|
| Rate limiting        |
| DDoS protection      |
| Bot detection        |
| Traffic filtering    |
+----------+-----------+
           |
           v
        Backend

This is called admission control.

3. Admission control: don't accept unlimited work

Imagine a nightclub with capacity for 500 people.

There are 20,000 people waiting outside.

You would not allow all 20,000 inside and then decide what to do.

There is a bouncer.

In distributed systems, the "bouncer" could be:

Rate limiting
Bot protection
Concurrency limits
Queues
Load shedding

The principle is:

Protect expensive downstream systems by limiting how much work enters.

This pattern appears everywhere:

flash sales
online exams
ticket launches
gaming events
IPO applications
payment systems

4. Then comes the load balancer

One server cannot handle millions of requests.

So we run many API servers.

                Load Balancer
                     |
        ---------------------------
        |            |            |
        v            v            v
      API-1        API-2        API-100

The load balancer spreads requests across them.

This is horizontal scaling.

Instead of buying one giant server, we add more servers.

If one server handles roughly:

5,000 requests/second

then 100 servers could theoretically handle around:

500,000 requests/second

Actual capacity depends on the workload, but the pattern is what matters.

5. API servers should be stateless

Here is an important mistake.

Suppose API Server 1 stores this in memory:

availableSeats = 4

And API Server 2 also stores:

availableSeats = 4

Now both servers might independently sell those four seats.

That is obviously wrong.

So critical shared state should not live independently inside each API server.

Instead:

API-1 -----\
API-2 ------\
API-3 -------> Shared Inventory Service
API-4 ------/

The API servers are mostly stateless.

This makes scaling easier because any request can go to any server.

If Server 27 crashes, the load balancer simply routes traffic elsewhere.

A useful mental model is:

Stateless compute is easy to scale. Shared mutable state is where distributed systems become difficult.

6. Now we reach the real problem: race conditions

Suppose only one seat remains.

availableSeats = 1

Two servers receive booking requests almost simultaneously.

Server A does:

READ availableSeats

It sees:

Server B also does:

READ availableSeats

It also sees:

Both then say:

seat is available
book it

Now one seat has been sold to two users.

This is a race condition.

The timeline looks like:

Time →

Server A    READ seats = 1
Server B        READ seats = 1
Server A            WRITE seats = 0
Server B                WRITE seats = 0

Both requests believed they succeeded.

7. The fix: atomic operations

The mistake above is that we did this:

READ
CHECK
WRITE

as separate steps.

Instead, the check and update should behave like one indivisible operation.

Conceptually:

IF seats > 0
THEN seats = seats - 1

One database implementation might look like:

UPDATE inventory
SET available_seats = available_seats - 1
WHERE train_id = ?
  AND available_seats > 0;

Suppose one seat remains.

Request A executes first:

1 → 0

Success.

Request B executes next.

The condition:

available_seats > 0

is false.

So Request B fails.

No overselling.

This property is called atomicity.

Either the whole operation happens or none of it happens.

8. Great, so let 25 lakh requests hit this SQL query?

Not so fast.

The query may be logically correct, but there is another problem.

All 25 lakh users want the same resource.

25 lakh requests
        |
        v
+----------------------+
| Train 12952          |
| Tatkal 3A            |
| available_seats = 4  |
+----------------------+

This single inventory record becomes extremely hot.

This is called a:

hot row
hot key
hotspot

Even if you have 10,000 application servers, they may all eventually fight over the same inventory record.

10,000 API servers
        |
        v
 same inventory row

This teaches an important lesson:

Scaling your application servers does not automatically scale shared state.

You see the same problem in:

concert tickets
Amazon flash sales
limited sneaker drops
coupon redemption
wallet balances
stock trading

9. Use a queue to absorb the burst

Instead of directly hammering the inventory system:

25 lakh requests
       |
       v
Inventory

we can place a queue in front:

25 lakh requests
       |
       v
+----------------+
| Booking Queue  |
+-------+--------+
        |
        v
     Workers
        |
        v
    Inventory

Now the huge incoming burst can be absorbed temporarily.

Requests may enter the queue as:

R1
R2
R3
R4
R5
...

Suppose four seats exist.

R1 → seat → 3 left
R2 → seat → 2 left
R3 → seat → 1 left
R4 → seat → 0 left
R5 → sold out

The important transformation is:

Huge uncontrolled concurrency

becomes:

Controlled processing

10. Why queues are useful

Queues decouple two different rates:

Rate at which requests arrive

and:

Rate at which the backend can process requests

Without a queue:

Traffic spike
>>>>>>>>>>>>>>>>>>>>>>>> DATABASE

With a queue:

Traffic spike
>>>>>>>>>>>>>>>>>>>>>

        |
        v

+----------------------+
|        Queue         |
| |||||||||||||||||||  |
+----------+-----------+
           |
           v

       Workers

----> ----> ----> Database

This is also a form of backpressure.

The downstream system says, in effect:

I will process work at the speed I can safely handle.

11. Should there be one global queue?

Probably not.

Imagine one queue for every booking in India.

Then a Delhi–Mumbai booking could block a completely unrelated Chennai–Bengaluru booking.

That wastes parallelism.

Instead, we partition the work.

A possible inventory key could be:

train_id + journey_date + class + quota

For example:

12952:2026-08-20:3A:TATKAL

All requests for the same inventory key should follow the same ordering path.

Different trains can be processed independently.

Train A → Partition 1 → Worker 1
Train B → Partition 2 → Worker 2
Train C → Partition 3 → Worker 3

This is partitioning or sharding.

12. The magic idea: serialize only conflicting work

This is one of the most reusable ideas in system design.

We do not need to serialize every booking in the country.

We only need to serialize requests that compete for the same inventory.

So instead of:

Every booking
    |
    v
one global worker

we do something closer to:

Same train/date/class/quota
          |
          v
   ordered processing

while unrelated inventory runs in parallel.

A good interview phrase is:

Serialize operations per inventory key, not globally.

That gives us both:

Correctness
+
Parallelism

13. So which four people actually win?

Now we can finally answer the original question.

The system may create an authoritative order somewhere inside its infrastructure.

For example:

User B → sequence 91821
User X → sequence 91822
User A → sequence 91823
User Z → sequence 91824
User P → sequence 91825

There are four seats.

So:

91821 → gets seat
91822 → gets seat
91823 → gets seat
91824 → gets seat
91825 → sold out

The exact real-world click ordering may be impossible to know perfectly.

What matters is that the system defines one reliable ordering at a controlled point.

This leads to a broader distributed systems idea:

Sometimes we create an authoritative ordering instead of trying to discover the absolute real-world ordering.

14. What happens to the other 24,99,996 requests?

We ideally do not let every losing request perform an expensive database transaction.

Once the system confidently knows:

inventory = 0

future work can often be rejected earlier.

Instead of:

User
 |
 v
API
 |
 v
Queue
 |
 v
Worker
 |
 v
Database
 |
 v
Sold out

we may eventually do:

User
 |
 v
Booking Service
 |
 v
Sold out

This is called fail fast.

If an operation clearly cannot succeed, reject it as early and cheaply as possible.

This saves:

CPU
database connections
queue capacity
network calls
locks
memory

15. But be careful with caching

Suppose we cache:

Tatkal inventory = SOLD OUT

That is useful for fast rejection.

But what happens if someone fails payment?

The seat might become available again.

So we need to distinguish:

Cache

from:

Source of truth

A cache is fast, but it may be stale.

The authoritative inventory system decides the truth.

A good rule is:

Use caches to make the system faster, not to accidentally create a second source of truth.

16. Booking is not the same as confirmation

There is another important complication.

Imagine four users get seats, but payment takes two minutes.

Should those seats be permanently gone immediately?

Usually you need a temporary reservation.

The booking may move through states like:

AVAILABLE
    |
    v
HELD
    |
    v
PAYMENT_PENDING
    |
    +-----------+
    |           |
    v           v
CONFIRMED     FAILED
                |
                v
            AVAILABLE

Example:

4 seats

A → held
B → held
C → held
D → held

available = 0

Later:

A payment succeeds → confirmed

B payment fails → seat released

C succeeds → confirmed

D times out → seat released

This introduces several new system design topics:

TTLs
reservation expiry
state machines
retries
payment failures
compensation

These are natural follow-ups once the basic booking flow is correct.

17. Final high-level architecture

Putting everything together:

                       USERS
                         |
                         v
               +-------------------+
               | Edge / Cloudflare |
               |-------------------|
               | DDoS protection   |
               | Rate limiting     |
               | Bot detection     |
               +---------+---------+
                         |
                         v
               +-------------------+
               |   Load Balancer   |
               +---------+---------+
                         |
          +--------------+--------------+
          |              |              |
          v              v              v
       API-1           API-2          API-N
          \              |              /
           \             |             /
            +------------+------------+
                         |
                         v
               +-------------------+
               | Booking Service   |
               +---------+---------+
                         |
                         v
               +-------------------+
               | Booking Queue     |
               | partitioned by    |
               | inventory key     |
               +---------+---------+
                         |
             +-----------+-----------+
             |           |           |
             v           v           v
          Worker 1    Worker 2    Worker N
             |           |           |
             +-----------+-----------+
                         |
                         v
               +-------------------+
               | Inventory Service |
               +---------+---------+
                         |
                         v
               +-------------------+
               |    Database       |
               | Source of Truth   |
               +-------------------+

18. What did we actually learn?

The interesting part is not memorizing the architecture.

The important part is understanding why each component appeared.

Problem	Pattern
Millions of incoming requests	Horizontal scaling
Backend may collapse	Admission control
Bots generate unfair traffic	Rate limiting / bot protection
Many API servers	Stateless services
Two users can get the same seat	Atomicity
Millions hit the same inventory	Hotspot recognition
Huge burst at 10 AM	Queue
Backend slower than incoming traffic	Backpressure
Independent trains should run separately	Partitioning
Same inventory needs ordering	Per-key serialization
Inventory already exhausted	Fail fast
Repeated reads are expensive	Caching
System needs one correct answer	Source of truth

19. The most important system design habit

Do not start with:

We need Kafka.
We need Redis.
We need Cassandra.

Start with:

What problem do I have?
        |
        v
Why does it happen?
        |
        v
What is the simplest solution?
        |
        v
What breaks at scale?
        |
        v
What guarantee do I need?
        |
        v
Which system design pattern gives me that guarantee?
        |
        v
What new tradeoff did I introduce?

For example:

25 lakh requests
    ↓
backend overload
    ↓
admission control

Then:

traffic arrives faster than backend processes
    ↓
queue

Then:

multiple servers update same seat
    ↓
race condition
    ↓
atomic operation

Then:

everyone hits same inventory
    ↓
hotspot
    ↓
partition + serialize per key

That way, the architecture becomes a consequence of the problem instead of something you memorize.

20. The one sentence to remember

The hard part is not receiving 25 lakh requests. The hard part is safely coordinating millions of concurrent requests around a tiny amount of shared mutable state.

Once this idea makes sense, a lot of other systems start looking familiar:

concert ticketing
hotel bookings
airline seats
flash sales
stock trades
wallet balances
coupon redemption

The domain changes.

The underlying system design patterns repeat.

I Migrated a 61,000+ Line TypeScript Monorepo to Next.js 16.3 & TypeScript 7 — The Results Surprised Me

Harsh Mangalam — Thu, 06 Aug 2026 09:27:33 +0000

Performance improvements in release notes are always nice to read, but I've learned to take them with a grain of salt.

A benchmark on a small demo application rarely tells you how your production codebase will behave.

So I decided to benchmark one of my own projects after upgrading from Next.js 16.1 + TypeScript 5.8 to Next.js 16.3 + TypeScript 7.

The repository isn't enormous by enterprise standards, but it's large enough to expose real-world bottlenecks.

Project Overview

~61,000 lines of TypeScript
Turborepo monorepo
Multiple applications and shared packages
Bun as the package manager/runtime
Next.js frontend
Shared internal packages

I measured:

Cold type checking
Cached type checking
Development startup
Production build
Static page generation
Build output size

The Upgrade Path

One thing worth mentioning is that I couldn't jump directly to TypeScript 7.

My starting point was:

Next.js 16.1
TypeScript 5.8

Since Next.js 16.1 doesn't support TypeScript 7, I first upgraded Next.js to 16.3.

That migration was surprisingly smooth and required almost no code changes.

Once that was complete, I upgraded the monorepo to TypeScript 7.

Current Ecosystem Caveat

At the time of writing, typescript-eslint still doesn't fully support TypeScript 7.

That means:

tsc uses TypeScript 7
ESLint still performs its analysis using TypeScript 5.9

It's not a blocker, but it's something to be aware of if you upgrade today.

Benchmark 1 — Type Checking

Cold run before upgrading:

bun run typecheck

Tasks:    6 successful, 6 total
Cached:   0 cached
Time:     29.805s

After upgrading:

bun run typecheck

Tasks:    6 successful, 6 total
Cached:   0 cached
Time:     9.296s

Result

Version	Time
TS 5.8	29.8s
TS 7	9.3s

That's roughly a 3.2× improvement for a cold type check.

For a repository of this size, that's a significant reduction in feedback time.

Benchmark 2 — Turborepo Cache

Before:

259ms

After:

114ms

Already fast, but still noticeably quicker.

Benchmark 3 — Development Startup

Before:

bun run dev

Ready in 888ms

After:

bun run dev

Ready in 600ms

Not a massive difference, but enough to make restarting the dev server feel snappier.

Benchmark 4 — Production Build

Before:

time bun run build

real    0m52.044s
user    3m51.673s
sys     0m13.184s

After:

time bun run build

real    0m22.752s
user    0m58.419s
sys     0m8.791s

Result

Version	Build Time
Before	52.0s
After	22.8s

That's approximately 56% faster.

One interesting observation is the CPU time.

The previous build consumed almost four minutes of user CPU time.

After upgrading, that dropped to under one minute, suggesting the build process itself became considerably more efficient.

Benchmark 5 — Static Generation

Before:

Generating static pages (17/17) in 3.3s

After:

Generating static pages (17/17) in 3.2s

Essentially unchanged.

This suggests that most of the improvements came earlier in the build pipeline rather than during static page generation.

Benchmark 6 — Output Size

Before:

du -sh .next

50M

After:

du -sh .next

50M

The build output remained identical.

No regressions in generated artifacts.

Summary

Metric	Before	After
Cold typecheck	29.8s	9.3s
Cached typecheck	259ms	114ms
Dev startup	888ms	600ms
Production build	52.0s	22.8s
Static generation	3.3s	3.2s
`.next` size	50 MB	50 MB

My Observations

A few things stood out during the migration:

The Next.js upgrade itself was uneventful.
TypeScript 7 delivered the largest measurable improvement in day-to-day workflows.
Production builds became dramatically faster.
Output size remained unchanged.
Turborepo caching continued to work flawlessly.
The only missing piece today is full TypeScript 7 support in typescript-eslint.

Final Thoughts

I wasn't expecting a dramatic improvement.

The biggest surprise was seeing a full monorepo type check drop from nearly 30 seconds to just over 9 seconds.

Combined with a production build that finished in less than half the previous time, the upgrade noticeably improved the development experience without requiring significant application changes.

If you're maintaining a medium or large TypeScript monorepo, it's worth running your own benchmarks after upgrading.

Your numbers will differ, but the improvements may surprise you as much as they surprised me.

Have you upgraded to TypeScript 7 yet? I'd be interested to hear how your build times compare.

Your Go API Is Running—But Is It Healthy?

Harsh Mangalam — Mon, 20 Jul 2026 07:08:11 +0000

A Go server can start successfully and still be unable to handle real requests.

The process may be running while PostgreSQL is down. The API is alive, but it cannot do its main job.

That led me to a simple question:

If the server is running, is the application truly healthy?

Here is what I learned while building a useful health endpoint in Go.

What is a health endpoint?

A health endpoint is a small HTTP endpoint, usually something like:

GET /health

It is mainly used by Docker, Kubernetes, load balancers, and monitoring tools. These systems call the endpoint and decide whether the application should receive traffic.

Health checks are commonly split into three types:

Liveness: Is the application process running?
Readiness: Can the application handle traffic right now?
Startup: Has the application finished starting?

A liveness check should be simple. Restarting the application will not fix a database outage.

The endpoint in this post is closer to a readiness check because it checks PostgreSQL. If the database is unavailable, the application keeps running but reports that it is not ready for traffic.

Decide what the response should look like

I wanted the response to answer three questions:

Is the whole application healthy?
Which dependency failed?
How long did each check take?

That gave me these two structs:

type Response struct {
    Status    string                 `json:"status"`
    Checks    map[string]CheckResult `json:"checks"`
    Timestamp time.Time              `json:"timestamp"`
}

type CheckResult struct {
    Status     string `json:"status"`
    Error      string `json:"error,omitempty"`
    DurationMS int64  `json:"duration_ms"`
}

func (r Response) Healthy() bool {
    return r.Status == "healthy"
}

The JSON tags control the field names in the response. omitempty hides the error field when there is no error. The small Healthy method keeps the handler easy to read.

When PostgreSQL is available, /health returns 200 OK:

{
  "status": "healthy",
  "checks": {
    "postgres": {
      "status": "up",
      "duration_ms": 2
    }
  },
  "timestamp": "2026-07-20T10:30:00Z"
}

When PostgreSQL is unavailable, it returns 503 Service Unavailable:

{
  "status": "unhealthy",
  "checks": {
    "postgres": {
      "status": "down",
      "error": "ping postgres: connection refused",
      "duration_ms": 8
    }
  },
  "timestamp": "2026-07-20T10:31:00Z"
}

The HTTP status is important. A tool should not need to read the JSON just to learn whether the application is ready.

Give every dependency the same shape

PostgreSQL may not be the only dependency forever. An API might later need Redis, Kafka, or another internal service.

A small interface gives every health check the same shape:

type Checker interface {
    Name() string
    Check(ctx context.Context) error
}

Each checker provides a name for the response and returns an error when its dependency is unavailable.

The PostgreSQL checker is small:

type PostgresChecker struct {
    pool *pgxpool.Pool
}

func NewPostgresChecker(pool *pgxpool.Pool) *PostgresChecker {
    return &PostgresChecker{pool: pool}
}

func (c *PostgresChecker) Name() string {
    return "postgres"
}

func (c *PostgresChecker) Check(ctx context.Context) error {
    if err := c.pool.Ping(ctx); err != nil {
        return fmt.Errorf("ping postgres: %w", err)
    }

    return nil
}

Ping asks the connection pool to contact PostgreSQL. We do not need a large SQL query. A health check should be fast, cheap, and safe to run often.

Wrapping the error with ping postgres adds useful context when something fails.

Run the checks safely

The service has one job: run every checker and combine the results.

type Service struct {
    checkers []Checker
}

func NewService(checkers ...Checker) *Service {
    return &Service{
        checkers: append([]Checker(nil), checkers...),
    }
}

The constructor accepts any number of checkers and stores a copy of the list. The service begins each request with a healthy response and an empty map for the individual results:

response := Response{
    Status:    "healthy",
    Checks:    make(map[string]CheckResult, len(s.checkers)),
    Timestamp: time.Now().UTC(),
}

For each checker, it:

Creates a two-second timeout.
Records the start time.
Runs the check.
Saves its status, error, and duration.
Marks the whole response unhealthy if any check fails.

The important part looks like this:

checkCtx, cancel := context.WithTimeout(ctx, 2*time.Second)
defer cancel()

started := time.Now()
err := checker.Check(checkCtx)

result := CheckResult{
    Status:     "up",
    DurationMS: time.Since(started).Milliseconds(),
}

if err != nil {
    result.Status = "down"
    result.Error = err.Error()
}

Without a timeout, one stuck dependency could make /health wait forever.

The timeout is based on the incoming request context. If the caller disconnects, Go can cancel the remaining work instead of continuing a request nobody is waiting for.

Why run checks concurrently?

Imagine three dependencies:

PostgreSQL: 100 ms
Redis:      200 ms
Kafka:      300 ms

Running them one after another takes about 600 ms. Running them together takes about 300 ms, which is close to the slowest check.

The service starts one goroutine for each checker and uses a sync.WaitGroup to wait for all of them:

for _, checker := range s.checkers {
    wg.Add(1)

    go func(checker Checker) {
        defer wg.Done()
        // Run the check and build its result.
    }(checker)
}

wg.Wait()

The goroutines write to the same response map, so a sync.Mutex protects those writes:

mu.Lock()
response.Checks[checker.Name()] = result
if err != nil {
    response.Status = "unhealthy"
}
mu.Unlock()

With only one dependency, concurrency does not make the endpoint faster. Its value appears when more checks are registered.

Turn the result into HTTP

The handler runs the service, selects the status code, and writes JSON:

func (h *Handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    response := h.service.Check(r.Context())
    statusCode := http.StatusOK

    if !response.Healthy() {
        statusCode = http.StatusServiceUnavailable
    }

    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(statusCode)
    _ = json.NewEncoder(w).Encode(response)
}

Finally, the checker, service, and handler are connected in main.go:

postgresChecker := health.NewPostgresChecker(pool)
healthService := health.NewService(postgresChecker)

mux.Handle("GET /health", health.NewHandler(healthService))

One request now follows a clear path:

GET /health
    -> handler
    -> health service
    -> dependency checkers
    -> JSON response

A few practical rules

Health checks should stay lightweight. Avoid large queries, writes, or slow calls to external services.

Health is also not the same as monitoring. A health endpoint answers, "Can this instance receive traffic?" Metrics, logs, and traces explain how the application performs and why failures happen.

Be careful with error messages too. Detailed errors are helpful during development, but a public endpoint should not reveal passwords, connection strings, or other private information.

For a small codebase, all of this can live in one health.go file. Split it later when the file becomes harder to navigate, not simply because it might grow one day.

What I learned

A useful health endpoint is more than a hard-coded {"status":"ok"} response.

It needs clear output, correct HTTP status codes, fast dependency checks, timeouts, and safe handling of multiple checks. It should also know its limit: health tells us whether the application is ready, while monitoring tells us what is happening over time.

It is a small feature, but it makes an API much easier to operate and trust.

From http.ServeMux to Dependency Injection in Go: A Beginner-Friendly Guide

Harsh Mangalam — Fri, 17 Jul 2026 07:29:15 +0000

When I first saw code like this, it felt as if too many things were happening in one line:

mux.Handle("GET /health", health.NewHandler(healthService))

What is a mux? Why are we giving it a handler? How does the handler get the service? Who calls ServeHTTP?

This article answers those questions by starting with the smallest possible Go HTTP server and building toward a clean handler-and-service design one step at a time.

The big idea

An HTTP request moves through the application like this:

GET /health
     │
     ▼
HTTP server
     │
     ▼
ServeMux
     │
     ▼
Health handler
     │
     ▼
Health service
     │
     ▼
Dependency checker

Each part has one job:

The HTTP server receives requests.
The mux decides which handler should receive each request.
The handler translates between HTTP and our application.
The service performs the application logic.
A checker knows how to inspect one dependency, such as PostgreSQL.

Let us build this structure gradually.

Step 1: The smallest useful mux and handler

Go provides an HTTP router called http.ServeMux. A router matches an incoming request with the code that should handle it.

The method-and-path pattern used below, such as "GET /health", requires Go 1.22 or newer.

package main

import (
    "fmt"
    "log"
    "net/http"
)

func main() {
    mux := http.NewServeMux()

    mux.HandleFunc("GET /health", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "healthy")
    })

    if err := http.ListenAndServe(":8080", mux); err != nil {
        log.Fatal(err)
    }
}

There are three important lines here.

First, we create a mux:

mux := http.NewServeMux()

Second, we register a function for GET /health:

mux.HandleFunc("GET /health", func(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "healthy")
})

This tells the mux:

When a GET /health request arrives, run this function.

Finally, we start the server and give it the mux:

http.ListenAndServe(":8080", mux)

The server receives requests, but the mux decides where they go.

If we run the program and send this request:

curl http://localhost:8080/health

we receive:

healthy

Step 2: Give the handler function a name

An anonymous function is convenient, but it becomes harder to read as it grows. We can move it into a named function:

func healthHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "healthy")
}

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("GET /health", healthHandler)

    if err := http.ListenAndServe(":8080", mux); err != nil {
        log.Fatal(err)
    }
}

Notice that we pass the function itself:

mux.HandleFunc("GET /health", healthHandler)

We do not call it:

// Wrong: this tries to call the function immediately.
mux.HandleFunc("GET /health", healthHandler())

The mux saves the function and calls it later when a matching request arrives.

Step 3: Introduce a service

Returning a fixed string does not require application logic. A real health endpoint may need to inspect PostgreSQL, Redis, or other dependencies.

We can put that logic in a service:

type HealthService struct{}

func (s *HealthService) Status() string {
    return "healthy"
}

For now, this service still returns a fixed value. That is okay—we are focusing on how the pieces connect.

One easy way to let the handler use the service is with a closure:

func main() {
    service := &HealthService{}
    mux := http.NewServeMux()

    mux.HandleFunc("GET /health", func(w http.ResponseWriter, r *http.Request) {
        status := service.Status()
        fmt.Fprintln(w, status)
    })

    if err := http.ListenAndServe(":8080", mux); err != nil {
        log.Fatal(err)
    }
}

The handler can use service because the function was created in the same surrounding scope.

The request now follows this path:

GET /health → mux → handler function → service.Status()

This is a good solution for a small program.

Step 4: Let a handler struct remember the service

As an application grows, a handler may need several methods or dependencies. A struct gives us a clear place to store them:

type HealthHandler struct {
    service *HealthService
}

The service field means every HealthHandler value remembers which health service it should use.

We create the handler with a constructor:

func NewHealthHandler(service *HealthService) *HealthHandler {
    return &HealthHandler{
        service: service,
    }
}

Passing a dependency into an object from the outside is called dependency injection. Despite the intimidating name, the idea is simple:

Create a value, then give it the things it needs.

The handler does not create its own service. main creates the service and passes it in.

Step 5: Understand the `http.Handler` interface

The standard library defines an interface that is approximately this:

type Handler interface {
    ServeHTTP(ResponseWriter, *Request)
}

Any type with a matching ServeHTTP method can act as an HTTP handler.

We can make our HealthHandler satisfy that interface:

func (h *HealthHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    status := h.service.Status()
    fmt.Fprintln(w, status)
}

We do not need to write implements http.Handler. Go recognizes automatically that *HealthHandler has the required method.

Now we can register it with mux.Handle:

func main() {
    service := &HealthService{}
    handler := NewHealthHandler(service)

    mux := http.NewServeMux()
    mux.Handle("GET /health", handler)

    if err := http.ListenAndServe(":8080", mux); err != nil {
        log.Fatal(err)
    }
}

When a matching request arrives, the mux effectively calls:

handler.ServeHTTP(w, r)

We do not call ServeHTTP ourselves. The standard library does it for us.

`HandleFunc` versus `Handle`

These two methods are similar, so they are easy to confuse.

Use HandleFunc when you have a function:

mux.HandleFunc("GET /health", func(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "healthy")
})

Use Handle when you have a value that implements http.Handler:

handler := NewHealthHandler(service)
mux.Handle("GET /health", handler)

A useful shortcut is:

function                         → HandleFunc
value with a ServeHTTP method    → Handle

Applying this to a real health-check package

Now let us return to the original line:

mux.Handle("GET /health", health.NewHandler(healthService))

It becomes easier to understand if we expand it:

healthHandler := health.NewHandler(healthService)

mux := http.NewServeMux()
mux.Handle("GET /health", healthHandler)

The constructor stores the service inside the handler:

type Handler struct {
    service *Service
}

func NewHandler(service *Service) *Handler {
    return &Handler{
        service: service,
    }
}

The handler uses that stored service when a request arrives:

func (h *Handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    response := h.service.Check(r.Context())

    statusCode := http.StatusOK
    if !response.Healthy() {
        statusCode = http.StatusServiceUnavailable
    }

    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(statusCode)
    _ = json.NewEncoder(w).Encode(response)
}

The handler has a narrow responsibility:

Ask the service for the current health result.
Choose the correct HTTP status code.
Encode the result as JSON.

It does not know how PostgreSQL is checked. That responsibility belongs elsewhere.

Wiring the complete application

The clearest way to read the application wiring is one layer at a time:

pool, err := db.NewPostgres(ctx)
if err != nil {
    return fmt.Errorf("initialize postgres: %w", err)
}
defer pool.Close()

postgresChecker := health.NewPostgresChecker(pool)
healthService := health.NewService(postgresChecker)
healthHandler := health.NewHandler(healthService)

mux := http.NewServeMux()
mux.Handle("GET /health", healthHandler)

Each line gives one object to the next:

PostgreSQL pool
      │
      ▼
PostgreSQL checker
      │
      ▼
Health service
      │
      ▼
Health handler
      │
      ▼
ServeMux

The shorter version is equivalent:

mux.Handle("GET /health", health.NewHandler(healthService))

The expanded version is often easier to learn and debug. The shorter version is only a convenience; it is not a different design.

Follow one request from beginning to end

Suppose we run:

curl http://localhost:8080/health

Here is what happens:

The HTTP server receives GET /health.
The server passes the request to the mux.
The mux finds the handler registered for GET /health.
The mux calls healthHandler.ServeHTTP(w, r).
The handler calls healthService.Check(r.Context()).
The service runs its registered dependency checkers.
The PostgreSQL checker calls pool.Ping(ctx).
The result returns through the service and handler.
The handler sends JSON and either 200 OK or 503 Service Unavailable.

The dependencies are created from bottom to top during startup:

pool → checker → service → handler → mux

The request travels from top to bottom at runtime:

mux → handler → service → checker → pool

Seeing those as two separate moments—application startup and request handling—usually removes much of the confusion.

Why keep the service and handler separate?

We could put everything inside one handler function. That might be fine for a tiny experiment, but separating them gives us useful boundaries:

The handler deals with HTTP concepts such as request contexts, JSON, and status codes.
The service coordinates health checks and decides whether the application is healthy.
Each checker understands one external dependency.
main creates and connects the components.

This also makes future changes local. Adding Redis does not require changing the handler:

healthService := health.NewService(
    postgresChecker,
    redisChecker,
)

The handler still asks the same service the same question.

Common beginner misunderstandings

“Does the mux execute the handler during startup?”

No. Registering a handler only saves it for later:

mux.Handle("GET /health", healthHandler)

It executes after a matching request arrives.

“Why do we not call `ServeHTTP`?”

The HTTP server and mux call it. Our responsibility is to provide a value with the correct method.

“Is `NewHandler` special Go syntax?”

No. It is an ordinary function following a common naming convention for constructors:

func NewHandler(service *Service) *Handler

“Does the mux know about the service?”

No. The mux knows only about the handler. The handler knows about the service because the service was injected into it.

“Why use a pointer such as `*Handler`?”

The pointer lets the handler methods work with the same handler value and its stored dependencies without copying the struct. This is the usual pattern for stateful handlers.

Final mental model

If you remember only five ideas, remember these:

http.Server receives HTTP requests.
http.ServeMux chooses a handler based on the request path and method.
A type becomes an http.Handler by defining ServeHTTP.
A handler can store a service in a struct field.
main creates the dependencies and connects them together.

The line that once looked complicated:

mux.Handle("GET /health", health.NewHandler(healthService))

now reads naturally:

Create a health handler that uses this health service, then register it for GET /health.

That is the core of mux, handlers, and dependency injection in Go.

How Next.js Image Optimization Works Under the Hood

Harsh Mangalam — Thu, 16 Jul 2026 06:39:54 +0000

When I first started using Next.js, I replaced every <img> with <Image /> because the documentation said it was "optimized."

It worked.

But I had one question:

What is it actually doing behind the scenes?

After digging into it, I realized the idea is much simpler than I expected.

Let's walk through it together.

The problem with a normal `<img>`

Imagine you have a beautiful travel photo.

taj-mahal.png
4000 × 3000
6 MB

You display it on your website like this:

<img src="/taj-mahal.png" />

When someone opens your page, the browser asks the server for that image.

Browser
   │
   ▼
GET /taj-mahal.png
   │
   ▼
Server sends 6 MB image

The browser downloads the entire file.

Now imagine your image is only shown inside a small card that's 300 pixels wide.

The browser still downloads the full 4000-pixel image.

That means you're downloading way more data than you actually need.

What would be the smarter approach?

Instead of sending the same image to everyone, what if we could do this?

For phones:

300 px image

For tablets:

600 px image

For desktops:

1000 px image

Everyone sees the same picture, but only downloads the size they actually need.

That is the main idea behind image optimization.

Enter Next.js `<Image />`

Instead of writing

<img src="/taj-mahal.png" />

we write

<Image
  src="/taj-mahal.png"
  width={500}
  height={300}
/>

Looks almost the same.
But behind the scenes, something very different happens.

The first surprise

You might think the browser requests this:

GET /taj-mahal.png

It doesn't.

Instead, it requests something like this:

GET /_next/image?url=/taj-mahal.png&w=640&q=75

At first, this looked strange to me.

Why isn't it requesting the actual image?

Meet the Image Optimizer

That /_next/image URL is a special endpoint created by Next.js.

Instead of sending the original image directly, the request goes through the optimizer first.

Browser
    │
    ▼
Next.js Image Optimizer
    │
    ▼
Original Image

You can think of it as a smart middleman.

Before giving the browser the image, it asks:

What size do you need?
What quality should I use?
Which image format does your browser support?

Then it prepares the best version.

What happens when the request arrives?

Suppose the browser sends:

GET /_next/image?url=/taj-mahal.png&w=640&q=75

Next.js now knows:

Original image location
Required width (640px)
Image quality (75)

Now the real work begins.

Step 1 — Load the original image

Next.js finds the original image.

It might come from:

your public folder
an external URL
cloud storage like S3

The optimizer first loads the original image into memory.

Step 2 — Resize it

Suppose the original image is

4000 px wide

But the browser only needs

640 px

There is no reason to send all 4000 pixels.

Next.js resizes the image to the requested width.

4000 px

↓

640 px

This alone saves a lot of bandwidth.

Step 3 — Compress it

Even after resizing, the image can often be made much smaller.

If the quality is set to 75, Next.js compresses it while trying to keep it looking almost identical.

For example:

400 KB

↓

90 KB

The user usually can't notice the difference, but their internet connection definitely can.

Step 4 — Choose a better format

Modern browsers support formats like:

WebP
AVIF

These formats are usually much smaller than PNG or JPEG.

When your browser makes a request, it also sends an Accept header that tells the server which image formats it understands.

For example:

Accept: image/avif,image/webp,image/*,*/*

If the browser supports WebP or AVIF, Next.js may convert the original PNG or JPEG into one of those formats before sending it back.

Original

PNG

↓

Optimized

WebP

The picture looks almost identical but downloads much faster.

Step 5 — Cache the result

Image optimization isn't free.

Resizing and compressing images takes CPU time.

So Next.js stores the optimized version.

The first request looks like this:

Browser

↓

Next.js

↓

Resize

↓

Compress

↓

Cache

↓

Send image

The second request becomes much simpler.

Browser

↓

Next.js

↓

Cache

↓

Send image

No resizing.

No compression.

Just return the cached image.

How does the browser know which size to download?

This part surprised me the most.

Next.js doesn't generate just one image.

It generates multiple versions.

Something like:

320 px

640 px

750 px

1080 px

1920 px

It then generates an HTML srcset attribute.

Something similar to this:

<img
  src="/_next/image?url=/taj-mahal.png&w=640&q=75"
  srcset="
    /_next/image?url=/taj-mahal.png&w=320&q=75 320w,
    /_next/image?url=/taj-mahal.png&w=640&q=75 640w,
    /_next/image?url=/taj-mahal.png&w=1080&q=75 1080w
  "
  sizes="100vw"
/>

Now here's the interesting part.

Next.js doesn't decide which image gets downloaded.

The browser does.

If you're on a phone, it might download the 640px version.

If you're on a desktop with a Retina display, it might choose the 1080px version.

The browser looks at:

Viewport size
Device pixel ratio (Retina, 2x, 3x, etc.)
The sizes attribute

Then it picks the most appropriate image.

Why do we provide `width` and `height`?

One more nice feature.

When you write

<Image
  width={800}
  height={600}
/>

the browser already knows how much space the image will take.

Even before the image finishes downloading.

That means your page doesn't suddenly jump around while loading.

Without dimensions:

Header

Text

(Image loads)

Everything moves down

With dimensions:

Header

[Reserved Image Space]

Text

Everything stays stable.

This improves a Core Web Vitals metric called Cumulative Layout Shift (CLS).

Putting everything together

<Image />

      │
      ▼

Browser requests

/_next/image

      │
      ▼

Next.js loads the original image

      │
      ▼

Resize

      │
      ▼

Compress

      │
      ▼

Convert to WebP/AVIF (if supported)

      │
      ▼

Store in cache

      │
      ▼

Send optimized image to the browser

Final thoughts

Before learning this, I thought <Image /> was just another React component.

It turns out it's much more than that.

It's an image optimization pipeline built into Next.js.

Instead of sending every visitor the same large image, it creates a version that's appropriate for their device, browser, and screen size.

As developers, we only write one component.

Behind the scenes, Next.js handles resizing, compression, modern image formats, caching, and responsive images for us.

That's a lot of work hidden behind a single line of code.

If you enjoyed this article, the next logical step is understanding how srcset and sizes actually work. That's where the browser starts making intelligent decisions about which image to download, and it's one of the coolest parts of responsive images.

Stop Using react-error-boundary in Next.js? Meet next/error

Harsh Mangalam — Fri, 03 Jul 2026 06:30:57 +0000

For a long time, whenever I needed an Error Boundary in React, I reached for react-error-boundary.

It has been the go-to solution because React itself only provides the low-level Error Boundary API.

But if you're using Next.js App Router, there's now a much cleaner option.

Starting with Next.js 16, you can use the built-in next/error package.

Let's see why it matters.

The Old Way

Most React applications use react-error-boundary.

import { ErrorBoundary } from "react-error-boundary";

function ErrorFallback({ error, resetErrorBoundary }) {
  return (
    <div>
      <p>Something went wrong.</p>
      <button onClick={resetErrorBoundary}>
        Try Again
      </button>
    </div>
  );
}

export default function App() {
  return (
    <ErrorBoundary FallbackComponent={ErrorFallback}>
      <Dashboard />
    </ErrorBoundary>
  );
}

It works well, but it means:

Installing another dependency
Learning another API
Slightly different patterns from what Next.js already provides

If you're already using Next.js, that's no longer necessary in many cases.

Enter `next/error`

Next.js now ships with a helper called catchError.

Instead of wrapping your component with <ErrorBoundary />, you simply wrap your fallback component.

'use client';

import { catchError, type ErrorInfo } from 'next/error';

function ErrorFallback(props, { retry }: ErrorInfo) {
  return (
    <div>
      <p>Something went wrong.</p>

      <button onClick={() => retry()}>
        Try Again
      </button>
    </div>
  );
}

export default catchError(ErrorFallback);

That's it.

No extra package.

No separate Error Boundary component.

A Real Example

Here's an example with a nicer UI.

'use client';

import { AlertTriangle } from 'lucide-react';
import { catchError, type ErrorInfo } from 'next/error';
import { Button } from '@/components/ui/button';

function ErrorFallback(
  props: { title?: string; compact?: boolean },
  { retry }: ErrorInfo
) {
  if (props.compact) {
    return (
      <div className="flex flex-col items-center gap-2 px-4 py-4 text-center">
        <AlertTriangle className="text-danger h-4 w-4" />
        <p className="text-gray text-xs">
          {props.title ?? 'Something went wrong'}
        </p>

        <Button
          size="sm"
          variant="secondary"
          onClick={() => retry()}
        >
          Try again
        </Button>
      </div>
    );
  }

  return (
    <div className="flex flex-col items-center gap-3 px-5 py-10 text-center">
      <AlertTriangle className="text-danger h-6 w-6" />

      <p className="text-sm font-medium">
        {props.title ?? 'Something went wrong'}
      </p>

      <Button
        size="sm"
        variant="secondary"
        onClick={() => retry()}
      >
        Try again
      </Button>
    </div>
  );
}

export default catchError(ErrorFallback);

Notice that your fallback component receives two things:

props → Any custom props you pass.
ErrorInfo → Helpful methods like retry().

Calling retry() tells Next.js to attempt rendering the component again.

Why This Feels Better

The API is surprisingly simple.

Instead of this:

<ErrorBoundary FallbackComponent={ErrorFallback}>
  <Dashboard />
</ErrorBoundary>

You create an error boundary by exporting:

export default catchError(ErrorFallback);

Your fallback stays focused on displaying the UI.

Next.js handles the rest.

When Should You Use It?

If you're building a Next.js App Router application and only need client-side Error Boundaries, next/error is a great default.

It gives you:

✅ No additional dependency
✅ Smaller bundle
✅ Built into Next.js
✅ Retry support out of the box
✅ API that feels consistent with the framework

Should You Remove `react-error-boundary`?

If you're starting a new Next.js project, I'd probably reach for next/error first.

If you already have react-error-boundary everywhere, there's no urgent reason to rewrite everything overnight.

But for new components, using the built-in solution keeps your dependency list a little smaller and your code a little more aligned with Next.js.

Final Thoughts

One thing I like about recent Next.js releases is that they're gradually replacing common third-party utilities with built-in APIs.

next/error is another example of that.

It's a small addition, but it removes a dependency, simplifies your code, and gives you an Error Boundary API that feels like it belongs in the framework.

If you're using the App Router, it's definitely worth trying.

Resources

Next.js catchError documentation: https://nextjs.org/docs/app/api-reference/functions/catchError
Next.js 16 release notes: https://nextjs.org/blog

TypeScript is quietly killing baseUrl (and most people haven’t noticed yet)

Harsh Mangalam — Wed, 08 Apr 2026 05:13:34 +0000

If you’re seeing this warning:

Option 'baseUrl' is deprecated and will stop functioning in TypeScript 7.0

Yeah… it’s real.

For years, we’ve been doing this 👇

{
  "extends": "@workspace/typescript-config/bun.json",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  }
}

But TypeScript is moving away from module resolution hacks.

💡 The shift
TypeScript no longer wants to resolve your imports.

👉 Your runtime / bundler should do that (Bun, Vite, Next, etc.)
👉 TypeScript should just type-check

✅ The simple fix
Just remove baseUrl.

{
  "extends": "@workspace/typescript-config/bun.json",
  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

⚡ Why this matters

Future-proof (TS 7 won’t break you)
Cleaner separation of concerns
Matches modern tooling direction

🧩 Why Dialog Doesn’t Work When Wrapped with Tooltip in Radix / ShadCN UI (And How to Fix It)

Harsh Mangalam — Thu, 07 Aug 2025 17:37:45 +0000

When working with Radix UI (used under the hood in shadcn/ui), things are usually smooth — composable, accessible, and beautifully engineered.

But one day, I wrapped a DialogTrigger with a Tooltip and…

Nothing happened.

No errors. No warnings. Just a button that didn’t open the dialog. 🤯

Turns out, there's a common but sneaky mistake that trips up many devs — and it’s all about the order in which you nest your components.

❌ The Broken Version

This is what I initially wrote — trying to wrap my dialog trigger in a tooltip:

<Dialog open={open} onOpenChange={setOpen}>
  <DialogTrigger asChild>
    <Tooltip>
      <TooltipTrigger asChild>
        <Button size="icon" variant="outline">
          <EditIcon />
        </Button>
      </TooltipTrigger>
      <TooltipContent>Edit podcast</TooltipContent>
    </Tooltip>
  </DialogTrigger>
  <DialogContent className="max-w-4xl max-h-[80vh] overflow-y-auto">
    {/* Form goes here */}
  </DialogContent>
</Dialog>

At first glance, this looks totally fine.

But the dialog wouldn’t open when clicking the button.
The tooltip shows, but the dialog never appears.

🤔 What’s Going Wrong?
Let’s break this down.

Both DialogTrigger and TooltipTrigger from Radix use the asChild prop, which means:

They don’t render any DOM element themselves.

Instead, they pass event handlers like onClick to their child — which must be a real DOM element, like a .

In the broken example, DialogTrigger wraps Tooltip, which is not a DOM element — it's just a React component.
So the click event never reaches a usable target for Dialog.

✅ The Working Version
Here’s the corrected nesting:

<Dialog open={open} onOpenChange={setOpen}>
  <Tooltip>
    <TooltipTrigger asChild>
      <DialogTrigger asChild>
        <Button size="icon" variant="outline">
          <EditIcon />
        </Button>
      </DialogTrigger>
    </TooltipTrigger>
    <TooltipContent>Edit podcast</TooltipContent>
  </Tooltip>
  <DialogContent className="max-w-4xl max-h-[80vh] overflow-y-auto">
    {/* Form goes here */}
  </DialogContent>
</Dialog>

Why does this work?

TooltipTrigger passes props down to DialogTrigger
DialogTrigger passes props down to the final Button
The Button becomes the single, shared DOM element that receives both behaviors

🧠 Rule of Thumb

Always place the outermost wrapper (like Tooltip) outside, and the final DOM element (like Button) inside both DialogTrigger and TooltipTrigger, using asChild.

Understanding Legacy Promise Throwing Behavior in React

Harsh Mangalam — Mon, 06 Jan 2025 06:39:14 +0000

React is a powerful and versatile JavaScript library used for building user interfaces. One of its modern features, Suspense, allows components to handle asynchronous data gracefully. However, the concept of "Legacy Promise Throwing Behavior" in React often causes confusion among developers. This blog post aims to break down what this behavior entails, how it fits into React’s rendering process, and why it’s important to understand when working with concurrent features.

What Is Legacy Promise Throwing Behavior?

Legacy Promise Throwing Behavior refers to the mechanism where React components "throw" a promise during rendering. This tells React that the component is waiting for some asynchronous data to be resolved before it can be fully rendered.

When a promise is thrown, React pauses rendering of that part of the component tree and instead renders a fallback UI, if defined, using Suspense. Once the promise resolves, React re-renders the component with the resolved data.

Key Features of Legacy Promise Throwing:

Throwing Promises During Rendering: Components can indicate they’re awaiting data by throwing a promise.
Integration with Suspense: This behavior works seamlessly with Suspense to show fallback content.
Asynchronous Data Handling: It provides a declarative way to handle async data fetching within React’s rendering lifecycle.

How Does It Work?

Let’s take a step-by-step look at how this behavior functions:

Component Throws a Promise: During rendering, a component encounters a promise and throws it.
Rendering Paused: React halts rendering for that branch of the component tree.
Fallback UI: If a Suspense boundary is present, React renders the fallback UI.
Promise Resolves: Once the promise resolves, React resumes rendering and integrates the resolved data.

Example of Legacy Promise Throwing

import React, { Suspense } from 'react';

// Simulated fetch function
function fetchData() {
  return new Promise((resolve) => {
    setTimeout(() => resolve("Data loaded!"), 2000);
  });
}

// Component that throws a promise
function AsyncComponent() {
  const data = useData(); // Custom hook
  return <div>{data}</div>;
}

function useData() {
  const promise = fetchData();
  if (!promise._result) {
    throw promise;
  }
  return promise._result;
}

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <AsyncComponent />
    </Suspense>
  );
}

export default App;

Explanation:

Fetching Data: The useData hook fetches data asynchronously using the fetchData function.
Throwing a Promise: If the data is not yet available, the promise is thrown.
Suspense Fallback: The Suspense component displays "Loading..." until the promise resolves.
Resolved Data: Once the promise resolves, the AsyncComponent renders the loaded data.

Modern React and Concurrent Features

React 18 introduced concurrent rendering, which refines how promise throwing works. Key improvements include:

Time-Slicing: React’s concurrent rendering splits work into smaller chunks, keeping the UI responsive even while waiting for async data.
Controlled Suspense Boundaries: Suspense boundaries handle promise throwing more gracefully.
Improved Error Handling: Better error boundaries for components that fail to fetch data.

Best Practices

While Legacy Promise Throwing is foundational to Suspense, developers should use modern libraries and patterns for a better experience:

Use React Query or SWR

Libraries like React Query and SWR provide robust solutions for data fetching, caching, and synchronization, eliminating the need to manually throw promises.

Leverage use Hook (React 18+)

React 18 introduced the use hook (experimental) for handling promises in a cleaner, declarative way.

function AsyncComponent() {
  const data = use(fetchData());
  return <div>{data}</div>;
}

Avoid Throwing Promises Directly

Throwing promises manually can lead to unexpected issues, especially in non-concurrent environments. Instead, rely on libraries or utilities that abstract these complexities.

Wrap Suspense for Reusability

Encapsulate Suspense logic in reusable components for cleaner code:

function WithSuspense({ children }) {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      {children}
    </Suspense>
  );
}

Conclusion

Legacy Promise Throwing Behavior is a cornerstone of React’s Suspense feature, enabling seamless handling of asynchronous data during rendering. However, as React evolves, so do the tools and patterns for managing async operations. By understanding this behavior and leveraging modern practices, developers can create efficient, responsive, and maintainable applications.

Mastering Literal Types in TypeScript: true as const vs true

Harsh Mangalam — Wed, 18 Dec 2024 12:03:12 +0000

In TypeScript, there is a significant difference between the two statements:

clientLoader.hydrate = true as const;
clientLoader.hydrate = true;

FYI I have picked these example from React router v7.

Let’s break down the difference with detailed explanations and examples

clientLoader.hydrate = true as const;

The as const assertion in TypeScript is a way of telling the TypeScript compiler to treat a value as its literal type, rather than the general type.
In this case, true as const means that the type of hydrate will be the literal true and not boolean. It essentially locks the value of hydrate to true specifically.

Example:

interface ClientLoader {
  hydrate: true;  // The type of hydrate is set to the literal value `true`
}

const clientLoader: ClientLoader = {
  hydrate: true as const,
};

clientLoader.hydrate = true; // This is valid

// clientLoader.hydrate = false; // Error: Type 'false' is not assignable to type 'true'

In the above example, clientLoader.hydrate is specifically typed as true. You cannot assign any value other than true to hydrate because of the as const assertion.
This type of assignment is useful when you want to enforce immutability for certain properties.

clientLoader.hydrate = true;

Without the as const assertion, TypeScript will infer the type of hydrate as boolean. This means that hydrate can be assigned any boolean value (true or false).

Example:

interface ClientLoader {
  hydrate: boolean;  // The type of hydrate is set to `boolean`
}

const clientLoader: ClientLoader = {
  hydrate: true,
};

clientLoader.hydrate = true;  // This is valid
clientLoader.hydrate = false; // This is also valid

In this case, since hydrate is typed as boolean, you can assign true or false to it.
It provides flexibility to switch between both true and false.

Feature	`clientLoader.hydrate = true as const;`	`clientLoader.hydrate = true;`
Type of hydrate	`true` (literal type)	`boolean` (general type)
Flexibility	Can only be `true`	Can be `true` or `false`
Use Case	When you want the property to be strictly `true` and not allow changes	When the property can hold any boolean value
Type Inference	The type of `hydrate` is narrowed to `true`	The type of `hydrate` is inferred as `boolean`

Why Use as const?

Enforcing Immutability: as const locks down the value so that it can’t be changed to something else. This is particularly useful when you want to ensure that a specific value is always the same throughout the program.
Literal Types for Discriminated Unions: When working with discriminated unions, as const allows you to create specific cases based on literal types, as shown below:

type Status = 'pending' | 'completed' | 'failed';

const status: Status = 'pending'; // 'pending' is a valid value

// status = 'in-progress'; // Error: Type '"in-progress"' is not assignable to type 'Status'

// With 'as const'
const taskStatus = 'pending' as const;
// Now taskStatus is narrowed down to the literal type 'pending'

Conclusion

Use as const when you want to assign a specific literal value to a property and enforce that the value remains fixed.
Use regular assignment (true, false, etc.) when you want to allow a property to accept different boolean values or when the exact value doesn’t need to be restricted.

This makes as const a useful tool for more precise typing and enforcing stricter value constraints in your TypeScript code.

Celebrating 100th Open Source Contributions: A Journey of Growth and Collaboration.

Harsh Mangalam — Tue, 27 Aug 2024 18:25:24 +0000

I'm thrilled to announce that I've reached a personal milestone: completing my 100th open-source contribution! This journey has been nothing short of incredible, and I'm honored to have contributed to a vibrant and diverse range of projects that have not only sharpened my skills but also allowed me to give back to the community that has given me so much.

My 100th contribution was made to the modular-forms library, an open source form library with performance, type safety and bundle size in mind.

If you're passionate about building cool stuff, check out my GitHub profile: https://github.com/harshmangalam – I'm always working on new and exciting projects!

A Look Back: My Open Source Journey

Over the years, I have had the privilege of contributing to a wide variety of open-source projects, each one teaching me something new and providing me with invaluable experiences. Here are some of the projects that I've been a part of:

Expo
Expo is a framework and platform for building cross-platform mobile applications using React Native. It simplifies the development process by providing a set of tools and libraries that handle common tasks like navigation, camera access, and push notifications. Expo's managed workflow allows developers to build, test, and deploy apps with minimal configuration and hassle.

Deno
Deno is a modern runtime for JavaScript and TypeScript built on V8 and Rust. It aims to improve security, simplicity, and performance by offering built-in TypeScript support, a secure sandboxed execution environment, and a single executable with no need for a package manager. Deno emphasizes a standard library and modularity, providing an alternative to Node.js with enhanced features for contemporary development.

Fresh.js
Fresh.js is a web framework for building high-performance applications with a focus on simplicity and speed. It is built on Deno and leverages its features to offer server-side rendering (SSR) and static site generation (SSG) out of the box. Fresh.js emphasizes minimal client-side JavaScript, optimizing performance by delivering fast initial loads and efficient updates. It uses a component-based architecture, similar to other modern frameworks, to facilitate building dynamic, reactive user interfaces.

Qwik
Qwik is a modern front-end framework designed for building high-performance, instantly loading web applications. It was developed by the team at Builder.io to address the performance limitations of traditional frameworks when it comes to building complex web applications

Qwik UI
Qwik UI is a component library designed to work seamlessly with the Qwik framework. It provides a set of pre-built, reusable UI components that can be used to quickly build user interfaces while taking full advantage of Qwik's unique performance characteristics. By leveraging Qwik's principles of resumability and instant loading, Qwik UI aims to deliver highly optimized and responsive user experiences.

Solid.js
SolidJS is a declarative, efficient, and flexible JavaScript library for building user interfaces. It emphasizes fine-grained reactivity, enabling high performance by updating only the parts of the DOM that change. Unlike other frameworks, SolidJS compiles components down to optimized, low-level JavaScript code, making it exceptionally fast. It offers a syntax similar to React, making it easy for React developers to transition. SolidJS also prioritizes simplicity and predictability, allowing developers to build complex applications with a straightforward and intuitive approach.

SolidStart
SolidStart is a full-stack framework built on top of SolidJS, designed for creating highly performant web applications. It provides features like server-side rendering (SSR), routing, and data fetching, making it easier to build scalable and efficient applications. SolidStart leverages SolidJS's fine-grained reactivity to deliver fast and seamless user experiences from the server to the client.

GraphQL Yoga
GraphQL Yoga is a fully-featured GraphQL server that is simple to set up and easy to use. It provides a flexible, plug-and-play architecture that supports various frameworks and environments, including Express, Fastify, and serverless functions. GraphQL Yoga includes features like subscriptions, real-time data, and file uploads out-of-the-box. It's designed to work seamlessly with TypeScript, offering type safety and developer-friendly tools. GraphQL Yoga aims to be lightweight yet powerful, making it suitable for both small projects and large-scale applications.

Shotstack
Shotstack is a cloud-based video editing API that enables developers to programmatically create, edit, and render videos. It offers a range of features like transitions, effects, text overlays, and audio integration, making it possible to automate video production tasks. Shotstack supports a wide array of media formats and can handle both 2D and 3D rendering

Remix.run:
Remix.run is a modern web framework focused on optimizing user experience and performance by leveraging server-side rendering (SSR) and client-side navigation. It emphasizes data fetching and caching strategies that improve speed and responsiveness. Remix enables developers to build robust and scalable applications with a strong emphasis on traditional web fundamentals like progressive enhancement and full-page reloads. It integrates well with various backends and APIs, allowing for flexible and efficient data management. Remix's architecture aims to provide a seamless user experience and a streamlined development process.

Deno SaaSKit
Deno SaaSKit is a SaaS boilerplate built on Deno, designed to accelerate the development of software-as-a-service applications. It provides essential features like authentication, billing, and multi-tenancy out-of-the-box. Deno SaaSKit leverages Deno's modern runtime and TypeScript support to deliver a secure, scalable, and maintainable foundation for SaaS projects.

Revoltchat
Revoltchat is an open-source alternative to Discord, designed for creating and managing online communities and chat environments. It offers features such as text and voice channels, user roles, and real-time messaging. Revoltchat emphasizes privacy and control, allowing users to host their own servers and manage data independently. The platform is built with a focus on flexibility and customizability, catering to various community needs and preferences.

Prisma
Prisma is a modern ORM (Object-Relational Mapping) tool for Node.js and TypeScript applications that simplifies database interactions. It provides a type-safe database client and a powerful schema management tool, allowing developers to define their data models using a declarative schema language. Prisma supports various databases, including PostgreSQL, MySQL, and SQLite, and offers features like automatic migrations and query optimization. It aims to streamline database workflows, improve developer productivity, and enhance the overall developer experience.

Drizzle ORM
Drizzle ORM is a lightweight, type-safe ORM (Object-Relational Mapping) library for TypeScript and JavaScript. It focuses on simplicity and performance, providing a straightforward API for querying and managing database records. Drizzle ORM supports various databases, including PostgreSQL, MySQL, and SQLite. It emphasizes type safety and minimal configuration, making it easier for developers to work with databases while ensuring reliable and maintainable code.

Open source is more than just code. It's about community, collaboration, and continuous learning. Every contribution I've made has been an opportunity to learn from others, share my knowledge, and solve real-world problems. Open source has given me the platform to experiment, innovate, and most importantly, connect with like-minded individuals who share the same passion for technology.

Looking Forward
As I celebrate this milestone, I am more motivated than ever to continue my journey in the open-source world. There are countless more projects to explore, more challenges to tackle, and more communities to engage with. I am excited about the future and the endless possibilities that lie ahead.

To everyone who has been part of this journey—thank you! Here's to the next 100 contributions and beyond!

Thanks.