DEV Community: Shubham Gupta

Understanding Back-of-the-Envelope Estimation in System Design

Shubham Gupta — Tue, 09 Jun 2026 16:04:59 +0000

When we use apps like YouTube, Instagram, WhatsApp, or Netflix, we rarely think about what happens behind the scenes.

Millions of users are watching videos, sending messages, uploading photos, and consuming content simultaneously. Yet these platforms continue to work smoothly.

One of the first questions engineers ask when building such systems is:

How big will this system become?

Before choosing databases, servers, caches, or cloud services, it's important to estimate the scale of the problem.

This is where Back-of-the-Envelope Estimation comes in.

What Is Back-of-the-Envelope Estimation?

Back-of-the-Envelope Estimation is a simple technique used to make quick calculations about a system's expected size and traffic.

The name comes from the idea that these calculations are so simple that they could be done on the back of an envelope.

The goal isn't perfect accuracy.

The goal is to understand whether you're dealing with:

Thousands of users
Millions of users
Billions of requests
Gigabytes of data
Terabytes of storage

These rough estimates help engineers make better design decisions.

Why Is Estimation Important?

Imagine someone asks you to build a photo-sharing application.
Before writing a single line of code, you'd probably want to know:

How many users will use it?
How many photos will be uploaded daily?
How much storage will be needed?
How much internet bandwidth will be consumed?

Without these answers, choosing the right architecture becomes difficult.

Estimation helps transform assumptions into measurable numbers.

Understanding Scale Through a Simple Example

Let's imagine a blogging platform with:

1 million users
Each user writes 1 blog per day
Average blog size is 5 KB

Daily storage:

text id=hm3zvn 1,000,000 × 5 KB = 5 GB per day

Yearly storage:

text id=iyu0sm 5 × 365 = 1.8 TB per year

A simple estimate immediately tells us that storage requirements will grow significantly over time.

Estimating User Traffic

Storage is only one part of the picture.

We also need to estimate how often users interact with the system.

Suppose:

1 million users
Each user reads 10 blogs per day

Total requests:

text id="70tqyv" 1,000,000 × 10 = 10 million requests/day

Requests per second:

text id="7q4i5s" 10,000,000 ÷ 86,400 ≈ 116 requests/second

This helps engineers understand the amount of traffic the system must handle.

Why Exact Numbers Don't Matter

One common misconception is that estimations must be perfectly accurate.

In reality, they rarely are.
User behavior changes.
Traffic patterns change.
Businesses grow unexpectedly.
The purpose of estimation is not to predict the future exactly.
It's to understand the order of magnitude of the problem.

Knowing whether a system needs to handle 100 requests per second or 100,000 requests per second is far more important than calculating the exact number.

Real-World Applications

Companies use estimation when building:

Video Streaming Platforms

Estimating:

Daily video uploads
Storage requirements
Streaming bandwidth

Social Media Platforms

Estimating:

Posts created per day
Feed requests
Notification traffic

Messaging Applications

Estimating:

Messages sent per second
Active users
Data storage growth

Cloud Storage Services

Estimating:

File uploads
Storage consumption
Download traffic

The Power of Simple Calculations

Many large-scale engineering decisions start with surprisingly simple math.

A few quick calculations can reveal:

Whether a single server is enough
Whether caching is required
How much storage is needed
How fast the system might grow

This is why estimation remains one of the most valuable skills in system design.

Key Takeaways

Back-of-the-Envelope Estimation helps understand system scale.
It focuses on rough calculations rather than perfect accuracy.
It helps estimate traffic, storage, bandwidth, and growth.
It allows engineers to make informed architectural decisions.
Every large-scale system begins with understanding its expected size.

Final Thoughts

Before building any system, it's worth asking a simple question:

"How big can this become?"

Back-of-the-Envelope Estimation provides a practical way to answer that question.

While the calculations are simple, the insights they provide can influence every architectural decision that follows.

Understanding scale is often the first step toward building systems that can grow and succeed over time.

How to Scale a Web Application from 0 to 1 Million Users: A System Design Journey

Shubham Gupta — Sat, 06 Jun 2026 12:59:22 +0000

Building an application is easy.

Building an application that can handle millions of users is where real engineering begins.

Many popular platforms such as Facebook, YouTube, Netflix, and Instagram started with a simple architecture. As their user base grew, their systems evolved to handle increasing traffic, data, and complexity.

In this article, we'll explore the journey of scaling a web application from a single server to a distributed system capable of serving millions of users.

Stage 1: Single Server Architecture

Every application starts small.

At this stage, a single server handles:

Frontend
Backend
Database
Static files

Users
  |
Application Server
  |
Database

Advantages

✅ Simple to build

✅ Low operational cost

✅ Easy deployment

Challenges

❌ Limited scalability

❌ Single point of failure

❌ Performance degradation as traffic grows

Stage 2: Separate the Database

As traffic increases, database operations become a bottleneck.

A common optimization is moving the database to a dedicated server.

Users
  |
Web Server
  |
Database Server

Benefits

Better performance
Independent resource allocation
Easier scaling

Stage 3: Introduce a Load Balancer

One application server eventually becomes insufficient.

A load balancer distributes incoming requests across multiple servers.

            Users
              |
       Load Balancer
          /      \
     App-1      App-2
          \      /
          Database

Why It Matters

Improved availability
Increased throughput
Better fault tolerance

Popular choices:

Nginx
HAProxy
AWS Elastic Load Balancer

Stage 4: Database Replication

As read traffic grows, the database becomes overloaded.

To solve this, databases are typically replicated.

Primary Database

Handles:

INSERT
UPDATE
DELETE

Replica Databases

Handle:

SELECT queries

Application Servers
        |
   Primary DB
        |
    Replicas

Benefits

Faster read operations
Reduced database load
Improved reliability

Stage 5: Add a Caching Layer

Many requests fetch the same data repeatedly.

Instead of hitting the database every time, store frequently accessed data in memory.

Request
   |
Redis Cache
   |
Database

Cache Flow

Request
   |
Cache Hit?
 /       \
Yes       No
 |         |
Return   Database
Data        |
         Store in Cache

Popular Technologies

Redis
Memcached

Benefits

Faster response times
Reduced database pressure
Better user experience

Stage 6: Use a CDN

Static assets such as images, CSS, JavaScript, and videos should be served closer to users.

A Content Delivery Network (CDN) helps achieve this.

User
 |
CDN
 |
Origin Server

Benefits

Lower latency
Faster page loads
Reduced bandwidth costs

Popular CDNs:

Cloudflare
AWS CloudFront
Akamai

Stage 7: Move to Stateless Servers

Storing user sessions inside application servers makes scaling difficult.

Instead, session data should be stored in:

Redis
Database
Distributed session storage

Benefits

Easy horizontal scaling
Improved reliability
Simpler deployments

Stage 8: Introduce Message Queues

Not every task needs immediate execution.

Examples:

Sending emails
Push notifications
Video processing
Analytics processing

Message queues allow these tasks to be processed asynchronously.

Application
      |
 Message Queue
      |
 Worker Services

Benefits

Faster user responses
Improved reliability
Better scalability

Stage 9: Scale Horizontally

When traffic continues growing, buying larger servers becomes expensive.

Instead, add more servers.

Vertical Scaling

2 CPU
4 CPU
8 CPU
16 CPU

Horizontal Scaling

Server 1
Server 2
Server 3
Server 4

Why Horizontal Scaling Wins

Better fault tolerance
Cost-effective growth
Virtually unlimited scalability

Stage 10: Microservices Architecture

As applications become larger, maintaining a single codebase becomes challenging.

The solution is splitting functionality into independent services.

Example:

User Service
Payment Service
Notification Service
Search Service
Content Service

Each service can:

Scale independently
Be deployed independently
Have its own database

Benefits

Faster development cycles
Better maintainability
Improved team productivity

Real-World Scaling Journey

Imagine you're building a blogging platform.

1,000 Users

Single Server

10,000 Users

Web Server + Dedicated Database

100,000 Users

Load Balancer + Multiple App Servers

1 Million Users

Redis Cache + CDN + Database Replication

10 Million Users

Microservices + Message Queues + Distributed Systems

Key Takeaways

Start with a simple architecture.
Scale only when necessary.
Separate application and database layers.
Use load balancers for high availability.
Add caching before scaling databases.
Use CDNs to deliver static content efficiently.
Keep application servers stateless.
Use message queues for asynchronous processing.
Prefer horizontal scaling over vertical scaling.
Adopt microservices when complexity demands it.

Final Thoughts

Scaling a system isn't about adding every technology on day one.

It's about identifying bottlenecks and solving them at the right time.

Every large-scale system follows a similar evolution:

Single Server → Database Separation → Load Balancer → Caching → CDN → Message Queues → Horizontal Scaling → Microservices

Understanding this journey is one of the most important foundations of System Design.

If you're preparing for system design interviews or building production-grade applications, mastering these concepts will give you a strong engineering mindset.

The Complete Guide to Resolving Git Merge Conflicts: From Beginner to Pro

Shubham Gupta — Sun, 31 May 2026 08:23:37 +0000

If you've been working with Git for a while, you've probably encountered a merge conflict at the worst possible moment—right before a release, during a hotfix, or while merging a large feature branch.

For many developers, especially beginners, merge conflicts can be intimidating. But here's the truth:

A merge conflict doesn't mean something is broken. It simply means Git needs your help deciding which changes should be kept.

In this guide, we'll dive deep into what merge conflicts are, why they happen, how to resolve them safely, and how professional teams minimize them.

What Is a Git Merge Conflict?

A merge conflict occurs when Git cannot automatically combine changes from two branches.

Git is usually smart enough to merge changes from different files or different parts of the same file. However, when multiple developers modify the same lines of code, Git doesn't know which version is correct.

Instead of making assumptions, Git stops the merge and asks for human intervention.

Understanding Git's Three-Way Merge

Before understanding conflicts, it's important to know how Git merges branches.

Imagine this scenario:

A --- B --- C (main)
       \
        D --- E (feature)

B is the common ancestor C contains changes from the main branch E contains changes from the feature branch

When merging, Git compares:

Common ancestor (B)
Main branch (C)
Feature branch (E)

This process is called a three-way merge.

If Git can combine changes safely, the merge succeeds automatically.

If not, a conflict occurs.

A Real Example

Let's say you're working on a React application.

Code in Main Branch

const API_URL = "https://api.production.com";

Meanwhile, another developer modifies the same line.

Code in Feature Branch

const API_URL = "https://api.staging.com";

Now Git sees:
Main wants Production URL
Feature wants Staging URL
Git cannot determine which one is correct.

Result:

CONFLICT (content): Merge conflict in config.js
Automatic merge failed; fix conflicts and then commit the result.

Types of Merge Conflicts

Content Conflicts

Most common conflict type.

Example:

function login() {
  return "Login Success";
}

Two developers modify the same line differently.
Git cannot choose automatically.

Delete vs Modify Conflicts

Developer A:

Deletes user.js

Developer B:

Adds new functionality to user.js

Git doesn't know whether the file should exist or not.

Rename Conflicts

One branch renames a file while another branch edits it.

Example:

auth.js → authentication.js

At the same time another developer updates auth.js.

Git needs clarification.

Binary File Conflicts

Files such as:

Images
PDFs
Videos cannot be merged line by line. Git requires manual selection.

How to Reproduce a Conflict

Let's create one intentionally.

Step 1: Create Feature Branch

git checkout -b feature-login

Modify:

const version = "v1";

Commit:

git add .
git commit -m "Update version in feature branch"

Step 2: Switch Back to Main

git checkout main

Modify same line:

const version = "v2";

Commit:

git add .
git commit -m "Update version in main branch"

Step 3: Merge

git merge feature-login

Output:

Auto-merging app.js
CONFLICT (content): Merge conflict in app.js
Automatic merge failed.

Congratulations.
You now have a merge conflict.

Reading Conflict Markers

Git inserts markers into the file.

<<<<<<< HEAD
const version = "v2";
=======
const version = "v1";
>>>>>>> feature-login

Understanding these markers is crucial.

HEAD

Represents your current branch.

const version = "v2";

Incoming Changes
Represents the branch being merged.

const version = "v1";

Separator

=======

Separates both versions.

How to Resolve the Conflict

You have three choices.

Option 1: Keep Current Changes

const version = "v2";

Use when current branch is correct.

Option 2: Keep Incoming Changes

const version = "v1";

Use when merged branch contains desired code.

Option 3: Combine Both

Often the best solution.

const version = process.env.VERSION || "v2";

This preserves both ideas.

Completing the Merge

After editing:

git add app.js

Then:

git commit

Git creates a merge commit.

Verify:

git log --oneline --graph

Resolving Conflicts Using VS Code

VS Code provides built-in conflict resolution tools.
You'll see buttons such as:

Accept Current Change
Accept Incoming Change
Accept Both Changes
Compare Changes

Example:

Current Change
Incoming Change

Instead of manually editing markers, simply choose the appropriate option.
This is often the fastest approach.

Handling Conflicts During Rebase

Many teams prefer rebasing.

Example:

git rebase main

Conflict appears:

CONFLICT (content)

Resolve file.
Then continue:

git add .
git rebase --continue

If needed:

git rebase --abort

This restores branch to its original state.

Advanced Conflict Resolution Commands

View Conflicted Files

git status

Output:

both modified: app.js
both modified: config.js

See Exact Differences

git diff

Useful for understanding what changed.

Abort Entire Merge

git merge --abort

Returns repository to pre-merge state.

View Merge History

git log --graph --all --decorate

Helps visualize branch history.

Best Practices Used by Professional Teams

1. Pull Latest Changes Frequently

Don't work on stale code.

git pull origin main

Regular updates reduce conflicts.

2. Keep Branches Short-Lived

Bad:

Feature branch open for 3 weeks

Good:

Feature branch merged within 1-3 days

3. Create Smaller Pull Requests

Smaller PRs:

Easier reviews
Faster merges
Fewer conflicts

4. Use Feature Flags

Instead of long-lived branches:

if (featureFlagEnabled) {
  // new feature
}

This minimizes divergence.

5. Communicate Early

If multiple developers are modifying:

Authentication
Payments
Shared components Coordinate before coding. A 5-minute discussion can save hours of conflict resolution.

Common Mistakes Developers Make

Deleting Conflict Markers Incorrectly
Wrong:

<<<<<<< HEAD

Leaving markers causes syntax errors.
Always remove them completely.

Resolving Without Understanding Code

Never blindly click:

Accept Current

Accept Incoming

Understand the business logic first.

Skipping Testing

After resolving:

npm test

npm run build

Always verify functionality.

Real Production Story

A team member once resolved a conflict by keeping only their own changes.
The application compiled successfully.
However, the conflict resolution removed a critical authentication check added by another developer.
The bug wasn't discovered until production deployment.
The lesson:
Successful merging doesn't guarantee correct merging.
Always review the final code carefully.

Key Takeaways

✅ Merge conflicts are normal.
✅ They happen when Git cannot decide between competing changes.
✅ Learn to read conflict markers confidently.
✅ Use tools like VS Code to simplify resolution.
✅ Pull frequently and keep branches small.
✅ Test thoroughly after resolving conflicts.

Conclusion

Merge conflicts are a fundamental part of collaborative software development. Every professional developer encounters them regularly.

The difference between a beginner and an experienced engineer isn't avoiding merge conflicts—it's resolving them confidently and safely.

Once you understand how Git thinks, merge conflicts become less of a roadblock and more of a routine step in your development workflow.

Have you ever faced a merge conflict that took hours to resolve? Share your story in the comments—I'd love to hear how you handled it! 🚀

Things Nobody Tells You About Building Chrome Extensions

Shubham Gupta — Mon, 18 May 2026 19:01:37 +0000

When I started learning Chrome extension development, I thought it would be easy.

I already knew:

React
JavaScript
APIs
Node.js

So I assumed:
“Building a browser extension should take only a few hours.”

I was wrong. 😅

Chrome extensions work very differently from normal web applications.

You need to understand:

manifests,
permissions,
content scripts,
service workers,
browser security,
an extension architecture.

In this article, I’ll explain the things that confused me the most while building my first Chrome extension.

If you’re a beginner, this guide may save you many hours.

First, What Is a Chrome Extension?

A Chrome extension is a small application that runs inside the browser.

Extensions can:

modify webpages,
automate tasks,
save notes,
block ads,
use AI,
summarize content,
and much more.

Examples:

Grammarly
Honey
Dark Reader
Momentum

All of these are browser extensions.

The Most Important File: manifest.json

The first confusing thing in Chrome extension development is the manifest.json file.

Think of it like the brain of your extension.

This file tells Chrome:

your extension name,
version,
permissions,
scripts,
icons,
popup pages,
and features.

Without this file, your extension will not work.

Example:

{
  "manifest_version": 3,
  "name": "My First Extension",
  "version": "1.0",
  "action": {
    "default_popup": "popup.html"
  }
}

At first this looks simple.

But as your extension grows, this file becomes very important.

What Is Manifest Version 3?

Most old tutorials use Manifest V2.

But Chrome now uses Manifest V3 (MV3).

This changes many things.

The biggest change:
background scripts are replaced with service workers.

This means:

extensions do not stay active all the time,
Chrome stops them when inactive,
and they restart only when needed.

As a beginner, this confused me a lot because I expected my extension to behave like a normal application.

Understanding Extension Parts

A Chrome extension usually has 4 main parts.

1. Popup

This is the small UI that opens when users click the extension icon.

Usually built using:

HTML
CSS
JavaScript
React

Example:

Todo popup
AI assistant popup
Note-taking UI

2. Content Script

This script runs inside websites.

It can:

read webpage content,
modify the DOM,
inject buttons,
extract text.

Example:
A YouTube summarizer extension reads video titles and transcripts using content scripts.

This was one of the hardest concepts for me initially.

3. Background Service Worker

This handles background logic.

Examples:

listening for browser events,
handling API calls,
managing notifications.

But unlike normal apps:
it does not stay alive forever.

This behavior creates many beginner bugs.

4. Storage

Extensions can save data using Chrome storage APIs.

Example:

saved notes,
settings,
AI prompts,
authentication tokens.

Permissions Are Extremely Important

Extensions often ask for permissions like:

tabs
storage
activeTab
scripting

Example:

"permissions": ["storage", "activeTab"]

At first I added many permissions without thinking.

But I later realized:
too many permissions make users suspicious.

Good extensions request only what they truly need.

Debugging Chrome Extensions Is Weird

Debugging normal apps is simple.

Chrome extensions are different because each part has separate DevTools.

You may debug:

popup console,
content script console,
background worker console.

I wasted a lot of time checking the wrong console 😅

Content Scripts Are Isolated

One thing nobody explains properly:

Content scripts run inside webpages…
but they are still isolated from the page itself.

This means:
some variables are inaccessible,
and some scripts behave differently.

At first this feels very confusing.

Chrome Security Is Strict

Chrome blocks many unsafe operations.

For example:

inline JavaScript,
unsafe eval(),
random external scripts.

This security system is called CSP (Content Security Policy).

Many libraries that work in React apps may fail inside extensions because of CSP restrictions.

Performance Actually Matters

Bad extensions can slow down the browser.

Especially when:

scripts run on every page,
bundles are too large,
or too many listeners exist.

I learned quickly that optimization matters even for small extensions.

Publishing Is Another Challenge

After building your extension, you still need:

store listing,
screenshots,
icons,
privacy policy,
proper permissions explanation.

Chrome Web Store reviews can reject extensions for small issues.

Final Thoughts

Chrome extension development is much more interesting than I expected.

At first it feels confusing.

But while building extensions, you learn:

browser architecture,
security,
performance optimization,
event-driven systems,
and real product engineering.

If you’re a beginner:
don’t worry if things feel strange initially.

Everyone gets confused by:

manifests,
content scripts,
and service workers at first.

Start with a small project,
experiment a lot,
and keep debugging.

That’s honestly the best way to learn Chrome extensions 🚀

Performance Optimization in Modern Web Applications

Shubham Gupta — Thu, 14 May 2026 07:32:23 +0000

Performance optimization is no longer an optional improvement for web applications — it is a core requirement. Users expect applications to load instantly, respond smoothly, and work reliably across devices and network conditions. Even a one-second delay in load time can reduce conversions, engagement, and user satisfaction.

In modern full-stack development, performance optimization spans frontend rendering, backend efficiency, database queries, network communication, caching, and deployment infrastructure. This blog explores practical strategies developers can use to build faster and more scalable web applications.

Why Performance Matters

Performance directly affects:

User experience
SEO rankings
Conversion rates
Retention and engagement
Infrastructure cost
Scalability

A slow application increases bounce rates and frustrates users. Search engines also prioritize faster websites, making performance optimization critical for visibility.

Frontend Performance Optimization

1. Reduce Bundle Size

Large JavaScript bundles slow down page loads.

Best Practices

Use tree shaking
Remove unused dependencies
Split code dynamically
Compress assets using Brotli or Gzip
Prefer lightweight libraries

Example (React Lazy Loading)

import React, { Suspense, lazy } from 'react';

const Dashboard = lazy(() => import('./Dashboard'));

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

This loads components only when required.

2. Optimize Rendering

Unnecessary re-renders can degrade UI responsiveness.

Techniques

Use React.memo
Memoize callbacks with useCallback
Use useMemo for expensive calculations
Avoid deep component nesting
Virtualize large lists

Example

const ExpensiveComponent = React.memo(({ data }) => {
  return <div>{data}</div>;
});

3. Image Optimization

Images often account for the largest portion of page weight.

Recommendations

Use WebP or AVIF formats
Lazy-load offscreen images
Serve responsive image sizes
Use CDN image optimization

Example

<img loading="lazy" src="image.webp" alt="optimized image" />

4. Improve Core Web Vitals

Google Core Web Vitals measure real user experience.

Key metrics include:

Largest Contentful Paint (LCP)
First Input Delay (FID)
Cumulative Layout Shift (CLS)

Optimization Tips

Preload important assets
Avoid layout shifts
Minimize blocking JavaScript
Use font optimization

Backend Performance Optimization

1. Database Query Optimization

Poor database queries create major bottlenecks.

Best Practices

Add proper indexes
Avoid N+1 queries
Use pagination
Optimize joins
Cache frequent queries

Example (MongoDB Index)

db.users.createIndex({ email: 1 });

2. Implement Caching

Caching reduces server load and response times.

Types of Caching

Browser caching
CDN caching
API caching
Redis in-memory caching
Database query caching

Example (Node.js + Redis)

const cachedData = await redis.get('users');

if (cachedData) {
  return JSON.parse(cachedData);
}

3. API Optimization

Efficient APIs improve both frontend and backend performance.

Recommendations

Compress API responses
Use pagination
Return only required fields
Implement rate limiting
Use GraphQL selectively

Example

GET /users?page=1&limit=20

4. Asynchronous Processing

Heavy tasks should run in the background.

Examples

Email sending
Video processing
Report generation
Notification delivery

Tools

BullMQ
RabbitMQ
Kafka
AWS SQS

Network Optimization

1. Use a CDN

A Content Delivery Network serves assets from servers closer to users.

Benefits include:

Faster load times
Reduced latency
Better scalability
DDoS protection

Popular CDNs:

Cloudflare
AWS CloudFront
Akamai
Fastly

2. Enable Compression

Compression significantly reduces response sizes.

Example (Express.js)

const compression = require('compression');
app.use(compression());

3. Minimize HTTP Requests

Reduce the number of requests by:

Combining assets
Using SVG icons
Removing unused scripts
Lazy loading modules

Performance Monitoring

Optimization should be data-driven.

Important Monitoring Tools

Lighthouse
Chrome DevTools
WebPageTest
New Relic
Datadog
Grafana

Metrics to Track

Page load time
API response time
Memory usage
CPU utilization
Error rate
Time to interactive

Scalability and Infrastructure Optimization

1. Load Balancing

Distribute traffic across multiple servers.

Popular Load Balancers

NGINX
HAProxy
AWS ALB

2. Horizontal Scaling

Instead of increasing server size vertically, scale by adding more servers.

Benefits:

Better reliability
Improved fault tolerance
Higher availability

3. Containerization

Docker and Kubernetes help manage scalable applications efficiently.

Advantages

Faster deployments
Resource isolation
Better scalability
Consistent environments

Common Performance Mistakes

Avoid these frequent issues:

Over-fetching data
Unoptimized database queries
Large frontend bundles
Memory leaks
Blocking operations
Excessive re-renders
Lack of caching
Ignoring monitoring

Real-World Optimization Workflow

A practical optimization process usually follows these steps:

Measure current performance
Identify bottlenecks
Prioritize high-impact fixes
Implement optimizations
Test under load
Monitor continuously

Performance optimization is iterative, not a one-time task.

Conclusion

Modern web applications require performance-focused engineering at every layer of the stack. From frontend rendering and asset optimization to backend caching and infrastructure scaling, each improvement contributes to a smoother user experience.

The best-performing applications are not necessarily the ones with the most features, but the ones that deliver fast, reliable, and efficient experiences consistently.

By adopting performance optimization best practices early in development, teams can build scalable systems that remain responsive as traffic and complexity grow.

Final Thoughts

Performance is a competitive advantage. Users notice speed, responsiveness, and reliability immediately. Investing in optimization improves user satisfaction, SEO performance, and operational efficiency.

A fast application is not just technically better — it is better for business.

When a Simple Streaming Bug Turned Into a Deep Engineering Lesson

Shubham Gupta — Wed, 06 May 2026 18:52:35 +0000

Recently, I worked on a streaming-related issue that initially looked very small.

Users reported that some long-duration videos were buffering unexpectedly during playback.

The pattern was interesting:

Videos started normally
Playback worked fine initially
After some time, buffering increased
In certain cases, playback stopped completely

At first, we assumed it could be:

A frontend player issue
Network instability
Device-specific behavior

Because for most users, buffering simply feels like “slow internet".

But after deeper investigation, we realised the actual problem was much more complex.

Understanding the Real Issue

After testing multiple scenarios, we noticed the issue mostly happened with:

Long-duration videos
Specific streaming versions
Quality switches during playback

Initially, video segments were loading correctly.

However, during longer playback sessions:

Segment loading became inconsistent
Buffer handling was delayed
Retry requests increased
Some quality-switch requests were not synchronizing properly

This created buffering loops that affected the viewing experience.

The challenging part was that the issue was not consistently reproducible.

Some videos worked perfectly.
Some failed only after extended playback durations.

That made debugging significantly harder.

How We Investigated

To identify the root cause, we started validating the following:

Multiple video durations
Different encoded versions
Various network conditions
Adaptive bitrate switching
Long playback sessions

We monitored:

Segment request timing
Retry behavior
Streaming responses
Buffer health
Playback synchronization

After deeper analysis, we found that certain streaming versions were not handling segment transitions efficiently during long playback sessions.

The Fix

To improve playback stability, we optimised the following:

Streaming response handling
Segment loading flow
Retry handling logic
Playback synchronization between streaming versions
Buffer management behavior

We then validated the fixes using:

Long-duration videos
Multiple streaming qualities
Different playback environments
Extended playback testing sessions

The improvements were immediately visible:

Playback became smoother
Buffering reduced significantly
Long-session streaming stabilized
Overall streaming consistency improved

What This Experience Taught Me

Before working closely with streaming systems, I thought video playback was mostly frontend-driven.

Now I understand the real complexity exists in:

Infrastructure
Scalability
Delivery optimization
Media pipelines
Buffer management
Performance engineering

Streaming platforms are one of the most fascinating examples of large-scale engineering.

Users only see a simple “Play” button.

Behind that button, thousands of engineering decisions work together in milliseconds to create a smooth viewing experience.

Smooth playback is not magic.

It’s engineering. ⚙️

Streaming #BackendEngineering #VideoStreaming #OTT #SoftwareEngineering #NodeJS #SystemDesign #PerformanceEngineering

Designing a Universal Error Handler for Frontend & Backend (React + Node.js)

Shubham Gupta — Thu, 22 Jan 2026 18:27:28 +0000

Error handling is one of those things we all do — but rarely design properly.

In most projects, error handling grows organically:

a few try/catch blocks
some HTTP status checks
random error messages sent from the backend
UI logic guessing what went wrong Eventually, the system becomes fragile.

This article walks through how and why I designed a universal error-handling system that works across Backend (Node.js / Express / Next.js APIs) and Frontend (React / Next.js UI) — using a shared contract, not tight coupling.

The Real Problem with Error Handling

Most applications suffer from the same issues:

Backend problems

Errors from DB, validation, or external APIs look different
Internal stack traces leak to clients
Error responses change over time
Hard to debug production issues

Frontend problems

Every API returns a different error shape
UI shows technical or confusing messages
Error handling logic is duplicated everywhere
Runtime crashes cause white screens The core issue isn’t missing try/catch.

👉 The issue is lack of design.

The Key Insight: Errors Are a Contract

Instead of treating errors as exceptions, I started treating them as data.
That led to one fundamental idea:

Frontend and backend should share an error contract, not implementations.

This single decision shaped the entire system.

Design Principle #1: Shared Contract, Not Tight Coupling

The frontend and backend do not depend on each other’s code.
They only agree on:

error codes
error structure

Example error contract:

{
  "success": false,
  "message": "User already exists",
  "code": "DUPLICATE_ERROR",
  "details": {
    "field": "email"
  },
  "traceId": "abc-123"
}

This gives us:

consistency
backward compatibility
freedom to evolve each layer independently

Design Principle #2: Backend Decides What Happened

The backend is the source of truth.

Its responsibility is to:

detect what went wrong
categorize the error
attach structured metadata
assign a stable error code

It does not decide how the error is shown.

Internally, the backend normalizes:
database errors
validation failures
authentication & authorization errors
third-party API failures
system-level crashes

Everything becomes a single, predictable error object.

Design Principle #3: Frontend Decides How to Show It

The frontend owns user experience.

It receives structured error data and decides:

the message shown to users
localization (i18n)
UI presentation (toast, banner, modal)
retry or recovery behavior

This allows the same backend error to be shown differently in:

admin dashboards
consumer apps
mobile vs desktop UIs

Technical message ≠ UI message — and that’s intentional.

Design Principle #4: Progressive Adoption

This system is not all-or-nothing.

You can:

use only backend utilities
use only frontend hooks
use both together for best results

Even if the backend doesn’t follow the contract perfectly, the frontend falls back safely.

This makes the library practical for:

legacy systems
gradual refactors
monorepos with mixed stacks

Design Principle #5: Hooks-Only, Modern React

All frontend APIs are built with hooks:

no class components
no outdated patterns

Some examples:

useAPIError() – handle API & network errors
useAsyncData() – async operations with built-in error state
useGlobalError() – app-wide error state
useNetworkStatus() – offline/online detection

Runtime UI crashes are handled via a React error boundary, wrapped once at the app root.

Design Principle #6: TypeScript-First

TypeScript isn’t an add-on — it’s the foundation.

strict typing
shared types between FE & BE
discriminated unions for error types
strong inference for consumers

This means:

fewer runtime surprises
safer refactors
better IDE experience

Types are the documentation.

End-to-End Flow (How Everything Connects)

Here’s the full journey of an error:

Backend detects a failure

Error is normalized into a standard structure
API returns a predictable error response
Frontend parses the error
Error code is mapped to a user-friendly message
UI displays a safe, meaningful response

At no point does the UI guess what went wrong.

Why This Matters in Production

This approach gives you:

cleaner APIs
better UX
safer production behavior
easier debugging (via trace IDs)
a shared mental model for teams

Error handling stops being “glue code” and becomes infrastructure.

The Result: A Universal Error Handler

I packaged this system as an open-source npm library:

npm install @shubhamgupta-oss/universal-error-handler

It works with:

React
Next.js
Node.js
Express
TypeScript
React 18 & 19

GitHub repo: https://github.com/shubhamgupta-oss/universal-error-handler
NPM package: https://www.npmjs.com/package/@shubhamgupta-oss/universal-error-handler

Final Thoughts

Good error handling isn’t about catching errors.

It’s about:

defining responsibility
designing contracts
respecting separation of concerns

Once you treat errors as a first-class system, everything else becomes simpler.

If you’re building full-stack applications and struggling with inconsistent error handling, I hope this approach helps.

Feedback, suggestions, and contributions are welcome. 🙌