DEV Community: Himanshu Gupta

Stop Assigning Permissions to Users. Build RBAC the Right Way

Himanshu Gupta — Thu, 16 Jul 2026 09:17:40 +0000

Every application starts the same way.

You launch your MVP with just one role:

Admin

A few weeks later, someone asks for an Editor.

Then comes:

Moderator
Manager
HR
Customer Support
Sales
Finance
Super Admin

Suddenly, your authorization logic looks like this:

if(user.isAdmin){
   ...
}

if(user.isManager){
   ...
}

if(user.department == "HR"){
   ...
}

if(user.role == "Finance"){
   ...
}

A few months later, the codebase becomes impossible to maintain.

Sound familiar?

This is exactly the problem Role-Based Access Control (RBAC) was designed to solve.

Why Direct Permissions Don't Scale

A common beginner approach is assigning permissions directly to users.

John

✓ Create User
✓ Delete User
✓ Edit User
✓ View Reports
✓ Create Posts
✓ Delete Posts

Now imagine your company has 50,000 users.

Changing one permission means updating thousands of records.

That's not scalable.

Instead, RBAC introduces one extra layer:

User
   ↓
Role
   ↓
Permissions

That single abstraction changes everything.

The Core Idea Behind RBAC

Instead of asking:

What permissions does this user have?

RBAC asks:

Which role does this user belong to?

Roles then define permissions.

For example:

Admin
 ├── Create Users
 ├── Delete Users
 ├── Edit Users
 └── Manage Roles

Editor
 ├── Create Posts
 ├── Edit Posts
 └── Publish Posts

Viewer
 └── Read Posts

If tomorrow every Editor needs a new permission...

You update one role, not thousands of users.

The RBAC Database Design

A production-ready RBAC system usually consists of five tables.

Users

Roles

Permissions

User_Roles

Role_Permissions

The two pivot tables are what make RBAC flexible.

Users

id
name
email

Roles

id
name

Admin
Editor
Manager
HR

Permissions

id
name

users.create
users.update
users.delete
posts.publish
reports.view

Notice the naming convention:

resource.action

This keeps permissions organized and predictable.

Many-to-Many Relationships

One user can have multiple roles.

John

↓

Admin

Manager

Likewise, one role can have many permissions.

Manager

↓

View Reports

Approve Leave

Assign Tasks

Database-wise:

Users

↓

User_Roles

↓

Roles

↓

Role_Permissions

↓

Permissions

This design eliminates duplication while remaining highly flexible.

Permission Resolution Flow

When a request arrives, the authorization flow typically looks like this:

User Request
      │
Authenticate User
      │
Load User Roles
      │
Load Role Permissions
      │
Merge Permissions
      │
Permission Exists?
      │
 YES ─────────→ Allow
 NO  ─────────→ Deny

The application never checks roles directly.

It checks permissions.

That's an important distinction.

Roles Should Never Exist in Business Logic

One mistake I see often is this:

if($user->role == "Admin"){
    // allow
}

The problem?

What happens when a new role called Super Admin is introduced?

Or Regional Manager?

Now every condition must be updated.

Instead:

$user->can('users.delete')

Now the application doesn't care which role grants the permission.

It only cares whether the permission exists.

This follows the Principle of Least Privilege and keeps your code extensible.

Why Pivot Tables Matter

Many developers ask:

Why not store permissions as JSON?

Because permissions change frequently.

Using pivot tables gives you:

Efficient joins
Referential integrity
Easy permission updates
Better indexing
Cleaner queries

Most importantly, it keeps your data normalized.

Caching Is Essential

Imagine every API request executes:

SELECT roles...

SELECT permissions...

JOIN role_permissions...

That quickly becomes expensive.

Instead, cache the final permission set immediately after authentication.

User Login

↓

Load Permissions

↓

Store in Redis

↓

Future Requests

↓

Redis Lookup

This eliminates unnecessary database queries and significantly improves performance.

RBAC with JWT Authentication

In stateless APIs, RBAC works seamlessly with JWT.

A typical flow is:

Login
   │
Generate JWT
   │
Load Roles
   │
Load Permissions
   │
Cache Permission Set
   │
Return Token

On each request:

JWT Validation
       │
Redis Cache
       │
Permission Check

This approach minimizes latency while keeping authorization centralized.

RBAC vs ABAC

RBAC isn't the only authorization model.

Another popular approach is Attribute-Based Access Control (ABAC).

RBAC

Manager

↓

Approve Expense

ABAC

Department == Finance

AND

Expense < $5000

AND

Business Hours

RBAC answers:

Who are you?

ABAC answers:

What are the current conditions?

Many enterprise systems combine both models.

Production Best Practices

A scalable RBAC implementation should follow these principles:

Never assign permissions directly to users.
Always use pivot tables for many-to-many relationships.
Follow a consistent resource.action naming convention.
Cache permissions after authentication.
Index pivot tables for faster joins.
Check permissions instead of roles in application code.
Keep authorization logic centralized in middleware or policies.

Popular RBAC Libraries

Most frameworks provide mature RBAC solutions.

Laravel

Spatie Laravel Permission

Spring Boot

Spring Security

ASP.NET

ASP.NET Identity

Node.js

CASL
AccessControl

These libraries implement the same architecture discussed above while handling caching, middleware, and authorization helpers for you.

Common Mistakes

❌ Assigning permissions directly to users

❌ Hardcoding role names in business logic

❌ Skipping permission caching

❌ Using comma-separated permission strings

❌ Storing permissions inside JWT tokens forever without refresh

❌ Ignoring database indexes on pivot tables

Avoiding these mistakes early can save countless hours as your application grows.

Final Thoughts

Role-Based Access Control isn't just about restricting access—it's about building an authorization system that remains maintainable as your application evolves.

The biggest shift in mindset is this:

Users shouldn't own permissions. Roles should.

By introducing a simple layer of abstraction, RBAC makes permission management cleaner, more scalable, and easier to extend.

Whether you're building a small SaaS product or an enterprise platform with millions of users, understanding RBAC fundamentals will help you design secure and maintainable applications.

What do you prefer for large-scale systems—pure RBAC, ABAC, or a hybrid approach? Share your experience in the comments!

#systemdesign #backend #rbac #security #authorization #softwarearchitecture #laravel #nodejs #java #developers

System Design: Designing LeetCode at Scale

Himanshu Gupta — Thu, 02 Jul 2026 12:06:51 +0000

LeetCode looks simple on the surface—browse coding problems, write code, and get instant feedback.

But behind that simple interface lies a distributed system capable of handling millions of developers, thousands of code submissions per second, and massive traffic spikes during coding contests.

In this article, we'll design a scalable version of LeetCode from scratch, covering everything from functional requirements to database choices, code execution, and leaderboard architecture.

Problem Statement

Design an online coding platform similar to LeetCode that allows users to:

Browse coding problems
Read problem statements
Write code in multiple programming languages
Submit solutions
Receive execution results within seconds
Participate in weekly coding contests
View live leaderboards

Functional Requirements

Our system should support the following features:

1. Browse Coding Problems

Users should be able to:

Search problems
Filter by difficulty
Filter by tags
Sort by popularity
Support pagination

2. View a Problem

Each problem contains:

Title
Description
Constraints
Sample Input
Sample Output
Hidden Test Cases
Supported Languages

3. Submit Solutions

Users should be able to:

Select a programming language
Write code
Submit code
Receive verdicts such as:
Accepted
Wrong Answer
Runtime Error
Compilation Error
Time Limit Exceeded (TLE)
Memory Limit Exceeded (MLE)

4. Contest Support

Support weekly and bi-weekly contests with:

Contest registration
Live rankings
Score calculation
Real-time leaderboard updates

Out of Scope

To keep the design focused, we'll ignore:

Authentication & Authorization
User Profiles
Payments
Notifications
Recommendation Engine
Analytics

Non-Functional Requirements

A production-grade coding platform must satisfy several quality attributes.

High Availability

During contests, thousands of users submit code simultaneously.

The platform should remain available even if individual services fail.

Low Latency

Users expect results within 2–5 seconds after submitting code.

Long delays lead to poor user experience.

Scalability

The system should support:

Millions of users
Thousands of concurrent submissions
Massive traffic spikes during contests

Horizontal scaling is preferred.

Security

Running arbitrary user code is extremely dangerous.

The execution environment must be:

Sandboxed
Isolated
Resource limited
Protected against malicious code

Fault Tolerance

No service should become a single point of failure.

The platform should continue operating even when individual components fail.

Capacity Estimation

Assume:

10 Million registered users
2 Million daily active users
100K concurrent users during contests
20K code submissions per minute

These numbers influence our infrastructure choices.

Core Entities

Problem

ProblemID
Title
Difficulty
Tags
Statement
Constraints
Hidden Test Cases

User

UserID
Username
Rating
Contest Rank

Submission

SubmissionID
ProblemID
UserID
Language
Code
Status
Execution Time
Memory Usage
Timestamp

Contest

ContestID
Start Time
End Time
Problems

Leaderboard

ContestID
UserID
Score
Penalty
Rank

REST APIs

Get Problems

GET /problems?page=1&difficulty=medium

Returns paginated problem lists.

Get Problem Details

GET /problems/{problemId}

Returns complete problem information.

Submit Solution

POST /problems/{problemId}/submit

Request:

{
  "language":"Java",
  "code":"..."
}

Response:

{
  "submissionId":"12345",
  "status":"Queued"
}

Submission Status

GET /submissions/{submissionId}

Returns:

Running
Accepted
Wrong Answer
Runtime Error

Contest Leaderboard

GET /contests/{contestId}/leaderboard

High-Level Architecture

                Users
                  │
            Load Balancer
                  │
             API Gateway
                  │
     ┌────────────┴─────────────┐
     │                          │
Problem Service         Submission Service
     │                          │
     │                    Message Queue
     │                          │
     │                  Code Execution Workers
     │                          │
     │                    Sandbox Containers
     │                          │
Database                Result Service
     │                          │
     └──────────────┬───────────┘
                    │
              Leaderboard Service

Why Use a Message Queue?

Code execution is time-consuming.

Instead of executing code synchronously:

User

↓

API

↓

Execute Code

↓

Response

We enqueue submissions.

User

↓

API

↓

Submission Queue

↓

Execution Workers

↓

Result

Benefits:

Better scalability
Retry failed executions
Load balancing
No API timeout

Popular choices:

Kafka
RabbitMQ
Amazon SQS

Code Execution Environment

This is the most critical component.

Running user code directly on servers is unsafe.

Instead:

Spin up isolated Docker containers
Apply CPU and memory limits
Restrict network access
Destroy the container after execution

Benefits:

Security
Isolation
Cost efficiency
Fast startup compared to Virtual Machines

Why Containers Instead of Virtual Machines?

Docker Containers	Virtual Machines
Lightweight	Heavy
Fast startup	Slow boot time
Better resource utilization	Higher resource usage
Lower cost	Higher cost
Easy horizontal scaling	More difficult to scale

For online judges, containers provide the best balance between performance and isolation.

Database Design

The platform stores different types of data.

Relational Database

Good for:

Users
Contests
Rankings
Transactions

Examples:

PostgreSQL
MySQL

NoSQL Database

Ideal for:

Problems
Test Cases
Submissions
Execution Logs

Examples:

DynamoDB
MongoDB
Cassandra

Since problem metadata rarely changes and submissions grow rapidly, NoSQL databases provide excellent scalability.

Caching

Popular problems are read far more often than they are updated.

We can cache:

Problem details
Test metadata
Contest information
Leaderboards

Using Redis significantly reduces database load and improves response times.

Live Leaderboard

Leaderboards are updated frequently during contests.

Instead of recalculating rankings after every submission:

Update scores asynchronously
Store rankings in Redis Sorted Sets
Push updates using WebSockets

This provides near real-time rankings with minimal latency.

Scaling Code Execution

Execution workers should scale independently.

During contests:

Normal Day

10 Workers

Contest

200 Workers

Using Kubernetes or container orchestration allows automatic scaling based on queue length.

Bottlenecks

Potential bottlenecks include:

Code execution workers
Message queue backlog
Database write throughput
Leaderboard updates
Large contest traffic spikes

Each component should be independently scalable.

Trade-offs

Every system design involves trade-offs.

Availability vs Consistency

We prioritize Availability.

A submission result delayed by a second is acceptable.

A platform outage during a contest is not.

This makes Eventual Consistency a practical choice for leaderboard updates.

Future Improvements

The platform can be extended with:

AI-powered code review
Code similarity detection
Plagiarism detection
Custom test cases
Interview mode
Company-specific problem sets
Multi-region deployment
Distributed execution clusters

Final Thoughts

Designing a platform like LeetCode is far more than storing coding problems.

It involves secure code execution, scalable infrastructure, asynchronous processing, distributed caching, and real-time leaderboards—all while maintaining low latency and high availability.

A robust design balances performance, security, and scalability to ensure developers receive instant feedback, even during the busiest coding contests.

As online coding platforms continue to evolve, incorporating AI-assisted code analysis, distributed execution environments, and intelligent recommendations will make these systems even more powerful.

How would you design the code execution engine? Would you choose Docker, Firecracker microVMs, or another sandboxing technology? Share your thoughts in the comments!

#systemdesign #leetcode #backend #softwarearchitecture #distributedsystems #microservices #cloud #programming #developers #coding

I Stopped Writing Better Prompts. I Started Designing Better AI Skills.

Himanshu Gupta — Thu, 02 Jul 2026 10:13:24 +0000

For the last two years, we've been obsessed with one thing:

Prompt Engineering.

Every tutorial promised the same result:

Better prompts
Better AI responses

But after working with modern AI coding agents, I realized something surprising.

The future isn't writing better prompts.

It's designing reusable AI capabilities.

That's exactly what Claude Skills represent.

The Problem With Prompt Engineering

We've all done this.

You write the perfect prompt.

Act as a senior software architect...

Follow clean architecture...

Use TypeScript...

Write tests...

Don't hallucinate...

It works beautifully.

Until tomorrow.

Then you paste the entire thing again.

And again.

Eventually your "perfect prompt" becomes a 700-line document that nobody wants to maintain.

Sound familiar?

Skills Change the Conversation

Instead of repeatedly telling the AI how to work...

You package that knowledge once.

Think of a Skill as something closer to a reusable software component than a prompt.

Prompt
↓

One Conversation

-------------------

Skill

↓

Unlimited Conversations

The difference is subtle.

The impact is enormous.

Great Skills Feel Like Good Software

After studying dozens of community-created Skills, I noticed something interesting.

The best ones follow the same principles as good software engineering.

Single Responsibility

Bad Skill

"Helps with development."

Good Skill

"Extract structured data from PDF forms."

One job.

Done exceptionally well.

Separation of Concerns

Instead of one massive instruction file:

Everything.md

Good Skills split responsibilities.

SKILL.md

↓

Reference Files

↓

Scripts

The AI only loads extra context when it actually needs it.

That's the AI equivalent of lazy loading.

Deterministic Over Generative

One of the biggest mistakes people make is asking AI to do work that code can do better.

Instead of saying

"Please parse this PDF carefully."

A better Skill simply executes a parser.

Instead of asking AI to calculate values...

Run Python.

Instead of asking AI to sort complex data...

Execute a script.

AI reasons.

Code computes.

The best Skills understand the difference.

Progressive Disclosure Is the Secret Sauce

One concept completely changed how I think about AI workflows.

Progressive Disclosure.

Imagine giving an intern a 500-page manual on their first day.

They won't read it.

Now imagine giving them one page.

Only when needed, you hand them another.

That's exactly how modern Skills work.

Only the minimum information is loaded first.

Additional documentation is fetched only if required.

Result?

Faster responses
Lower token usage
Better focus
Less hallucination

This may end up being one of the most important design patterns in AI engineering.

Stop Teaching AI Everything

Developers often try to build one "super prompt."

It usually looks like this:

Build websites

Write backend

Generate tests

Create documentation

Deploy code

Review security

Optimize SQL

Fix bugs

This is equivalent to writing one class that does everything.

We already know that's bad software design.

The same applies to AI.

Smaller, focused Skills consistently outperform giant instruction sets.

Think Like an API Designer

When designing a Skill, ask yourself:

Can another developer understand its purpose in one sentence?

If not...

It's probably trying to do too much.

Great APIs expose one responsibility clearly.

Great Skills should too.

AI Engineering Is Becoming Software Engineering

This is the biggest realization I've had.

As AI systems mature, the skills required to build them look increasingly familiar.

We're talking about:

Modularity
Reusability
Composition
Separation of concerns
Abstraction
Maintainability

Sound familiar?

That's software engineering.

Except now we're designing behavior instead of classes.

The New Development Stack

A few years ago our stack looked like this.

Frontend

↓

Backend

↓

Database

Now another layer is appearing.

Frontend

↓

Backend

↓

AI Agent

↓

Skills

↓

Tools

↓

External Systems

We're no longer building software.

We're building software that teaches other software how to work.

That's a very different challenge.

Skills Aren't Replacing Developers

One misconception is that Skills make AI autonomous.

They don't.

Skills capture expertise.

Developers still decide:

architecture
security
workflows
constraints
quality

Skills simply package those decisions into reusable capabilities.

Think of them as engineering playbooks.

My Biggest Takeaway

Prompt engineering taught us how to ask better questions.

Skill engineering teaches AI how to solve problems consistently.

That's a much bigger shift.

The companies that win with AI won't necessarily have the smartest models.

They'll have the best collection of reusable knowledge.

And I think that's where the industry is heading.

Final Thoughts

Every major shift in software development has introduced a new abstraction.

Functions replaced repetitive code.
Libraries replaced copy-paste utilities.
Frameworks replaced boilerplate.
Containers standardized deployment.

Now AI is introducing another abstraction:

Skills.

They're not just reusable prompts.

They're reusable expertise.

And if AI agents become the default way we build software over the next few years, learning how to design great Skills may become just as valuable as learning how to design great APIs.

What do you think?

Are AI Skills simply the next evolution of prompt engineering, or are they becoming a new layer of software architecture?

I'd love to hear your thoughts in the comments.

#ai #claude #claudecode #llm #softwareengineering #developers #productivity #agenticai #mcp #programming

API vs MCP: Understanding the Future of AI Integrations

Himanshu Gupta — Thu, 18 Jun 2026 07:45:27 +0000

As AI agents and Large Language Models (LLMs) become increasingly popular, developers often encounter a critical question:

Should I use APIs or MCP (Model Context Protocol)?

While both enable communication between systems, they solve very different problems. Understanding the distinction is essential when building modern AI-powered applications.

In this article, we'll break down the differences between APIs and MCP, explore their use cases, and help you decide when to use each.

What is an API?

An Application Programming Interface (API) is a set of rules that allows software applications to communicate with each other.

For decades, APIs have been the backbone of modern software development.

Common API Examples

Payment gateways
Weather services
Authentication systems
Social media integrations
E-commerce platforms

A typical API interaction looks like this:

Application
      ↓
    API
      ↓
  Database
      ↓
 Response

The developer writes code to call the API and process the response.

What is MCP?

Model Context Protocol (MCP) is an open protocol designed specifically for AI systems and Large Language Models.

Instead of requiring developers to manually explain every API endpoint to an AI, MCP enables AI models to discover and understand available tools dynamically.

Think of MCP as:

"A universal connector between AI models and external systems."

The interaction looks like this:

User
  ↓
LLM
  ↓
MCP Server
  ↓
Tools / APIs / Databases
  ↓
LLM
  ↓
User

The key difference is that the AI can understand what tools are available without extensive custom integration code.

The Fundamental Difference

APIs Are Built for Humans

Traditional APIs are designed with human developers in mind.

Developers must:

Read documentation
Understand endpoints
Write integration code
Handle authentication
Process responses manually

Example:

const response = await fetch('/api/orders');
const data = await response.json();

The application must know exactly what endpoint to call and how to use the result.

MCP Is Built for AI

MCP is designed for AI models.

Instead of manually defining every capability, the server tells the AI:

Available Tools:
✓ Get Orders
✓ Search Customers
✓ Create Invoice
✓ Check Inventory

The AI can then decide which tool to use based on the user's request.

This makes MCP particularly powerful for AI agents.

API vs MCP Comparison

Feature	API	MCP
Designed For	Human Developers	AI Models
Integration	Manual Coding	Dynamic Discovery
Documentation Required	Yes	Minimal
Communication Style	Request → Response	Context-Aware
Tool Discovery	No	Yes
AI Friendly	Limited	Native
Standardization	Per Service	Universal Protocol
Best For	Applications & Websites	AI Agents & LLMs

Why APIs Become Difficult for AI Agents

Imagine an AI assistant that needs access to:

CRM data
Customer database
Inventory system
Slack messages
Email platform
Analytics dashboard

With traditional APIs, developers need to:

Integrate every API separately.
Write custom logic.
Explain each endpoint to the AI.
Maintain integrations continuously.

This quickly becomes complex and difficult to scale.

How MCP Solves the Problem

MCP introduces a standard communication layer between AI models and external systems.

Instead of teaching the AI every API individually, MCP provides a common interface.

The AI simply asks:

What tools are available?

The MCP server responds with a list of capabilities.

The AI then uses the appropriate tool automatically.

This significantly reduces development effort.

Real-World Example

Using Traditional APIs

Suppose a user asks:

Show me my last 10 customer orders.

The developer must:

Create API endpoints
Write database queries
Parse responses
Format results
Send data back to the AI

The AI itself has no understanding of the available functionality.

Using MCP

The user asks:

Show me my last 10 customer orders.

The AI discovers:

GetRecentOrders()

The AI calls the tool through MCP.

The server returns data.

The AI generates a natural language response.

No custom explanation layer is required.

When Should You Use APIs?

APIs are still the best choice when building:

Mobile Applications

Android apps
iOS apps

Websites

E-commerce platforms
SaaS products
Dashboards

Traditional Software Systems

Backend services
Microservices
Enterprise integrations

If humans are consuming the application directly, APIs remain the standard solution.

When Should You Use MCP?

MCP shines when the end-user is an AI model.

Examples include:

AI Agents

Autonomous systems capable of:

Executing tasks
Accessing databases
Calling external services

AI Assistants

Assistants that need:

Customer data
Inventory information
Real-time business insights

Multi-Tool LLM Applications

Applications where AI interacts with:

Files
APIs
Databases
Chat platforms
Knowledge bases

MCP makes these integrations significantly easier.

MCP and the Future of Agentic AI

One of the biggest trends in AI is the rise of Agentic AI.

Agentic AI systems don't just answer questions—they take actions.

Examples:

Creating tickets
Updating databases
Sending emails
Managing workflows
Running business processes

To do this effectively, AI needs access to tools.

MCP provides the infrastructure that makes this possible.

This is why many developers consider MCP one of the most important technologies for the next generation of AI applications.

Choosing Between API and MCP

A simple rule:

Use APIs When:

✅ Humans are the primary users

✅ Building websites or mobile apps

✅ Traditional software integration is sufficient

Use MCP When:

✅ The end-user is an LLM

✅ Building AI agents

✅ Connecting AI to multiple systems

✅ Reducing custom integration code

Conclusion

APIs and MCP are not competitors—they solve different problems.

APIs remain the foundation of traditional software development.

MCP extends those capabilities into the world of AI by giving Large Language Models a standardized way to discover and use external tools.

As AI agents become more capable and autonomous, MCP is likely to become a critical part of modern software architecture.

The future isn't API vs MCP.

The future is:

APIs power systems.
MCP connects AI to those systems.

And together, they enable the next generation of intelligent applications.

What are your thoughts?

Have you started experimenting with MCP, or are you still building AI integrations using traditional APIs? Share your experience in the comments.

ai #mcp #api #llm #artificialintelligence #machinelearning #webdevelopment #softwareengineering #developers #agenticai

Model Context Protocol (MCP): The Missing Link Between AI Models and Real-World Applications

Himanshu Gupta — Thu, 18 Jun 2026 07:14:36 +0000

Large Language Models (LLMs) are powerful, but without access to real-world systems, databases, and APIs, their capabilities remain limited. This is where Model Context Protocol (MCP) comes in.

Introduction

Have you ever wondered how modern AI assistants can provide live weather updates, fetch the latest stock prices, access databases, or interact with external applications when their training data has a cutoff date?

The answer is simple: they don't rely only on their training data. Modern AI systems use external tools, APIs, and protocols to access real-time information.

One of the most important developments in this space is the Model Context Protocol (MCP).

In this article, we'll explore:

What MCP is
Why it is important
How it works
MCP architecture
Real-world use cases
Why MCP is becoming a standard for AI integrations

The Problem with Traditional LLMs

Traditional Large Language Models have a major limitation:

They are trained on historical data.
They cannot automatically access live information.
They cannot directly interact with databases, APIs, or business systems.

For example:

What is the weather in India right now?

A standard LLM can only answer based on its training knowledge.

But modern applications require:

Real-time weather data
Current stock prices
Latest news
Database access
Business workflow automation

This creates a gap between AI models and real-world systems.

What is MCP?

MCP (Model Context Protocol) is a standardized protocol that enables communication between AI models and external tools, APIs, databases, and applications.

Think of MCP as a universal bridge between:

AI Models ↔ External Systems

Instead of building custom integrations for every AI application, MCP provides a standardized way for models to interact with external resources.

Understanding MCP with a Simple Example

Consider this user request:

Show me my last 10 orders.

The AI model itself does not have access to your company's order database.

Instead, the flow looks like this:

User
  ↓
AI Model
  ↓
MCP Server
  ↓
Database/API
  ↓
MCP Server
  ↓
AI Model
  ↓
User

Step-by-Step Process

User asks for the last 10 orders.
AI analyzes the request.
AI identifies that external data is required.
AI calls an MCP tool.
MCP server connects to the database.
Latest orders are fetched.
Data is returned to the AI.
AI converts the data into natural language.
User receives the answer.

Why MCP Matters

Without MCP:

❌ AI cannot access live systems.

❌ Every integration requires custom development.

❌ Scaling AI integrations becomes difficult.

With MCP:

✅ Standardized communication

✅ Real-time data access

✅ API integrations

✅ Database connectivity

✅ File access

✅ Tool execution

✅ Better AI applications

MCP as a Universal Connector

A good analogy is the USB-C cable.

Years ago, different devices required different connectors.

Today, USB-C works across:

Phones
Laptops
Tablets
Accessories

Similarly, MCP aims to become the USB-C of AI integrations.

Instead of creating custom integrations for every AI model and tool combination, MCP provides one standard protocol that everyone can use.

MCP Architecture

A simplified architecture looks like this:

Frontend
   ↓
Backend
   ↓
LLM
   ↓
MCP Server
   ↓
Tools / APIs / Databases

Components

1. Frontend

The user interface where requests are submitted.

Examples:

React
Angular
Vue
Mobile Apps

2. Backend

Handles business logic and communicates with the AI system.

Examples:

Node.js
Express.js
Spring Boot
.NET

3. LLM

The AI model responsible for understanding user intent.

Examples:

GPT
Gemini
Claude
Llama

4. MCP Server

The central layer that exposes tools and resources to AI models.

Responsibilities include:

Tool registration
Request routing
Authentication
API communication
Database interaction

5. External Resources

Resources accessed through MCP:

APIs
Databases
Files
Business systems
Third-party services

What Does an MCP Server Do?

Tool Registration

The MCP server exposes tools such as:

GetOrders
GetCustomers
GetInvoices
SearchProducts

These tools become available to AI models.

Request Processing

The server receives tool calls and executes the appropriate logic.

Example:

Get latest customer orders

The MCP server:

Queries the database
Filters records
Formats results
Sends structured data back

Response Generation

The AI model then converts that structured response into natural language.

Example:

Here are your latest 10 orders...

Real-World Use Cases

E-Commerce

AI can:

Fetch customer orders
Track shipments
Search inventory
Process returns

CRM Systems

AI can:

Retrieve customer information
Create leads
Update records
Schedule follow-ups

Finance

AI can:

Access stock prices
Generate reports
Analyze transactions

Weather Applications

AI can:

Retrieve live weather information
Generate forecasts
Answer location-specific queries

Enterprise Systems

AI can interact with:

ERP platforms
HR systems
Internal databases
Knowledge bases

Benefits of MCP

Standardization

One protocol for multiple tools and systems.

Scalability

Add new tools without rebuilding integrations.

Flexibility

Works across different AI models.

Reusability

The same MCP server can serve multiple AI applications.

Faster Development

Developers can focus on business logic instead of integration complexity.

MCP and the Future of AI

As AI moves from simple chatbots to fully integrated business systems, real-world connectivity becomes essential.

Future AI applications will need:

Live data access
Workflow automation
Database interaction
API integrations
Enterprise connectivity

MCP provides the foundation for this future.

It transforms AI from a text-generation system into an intelligent assistant capable of interacting with real-world systems.

Conclusion

Model Context Protocol (MCP) is becoming one of the most important standards in the AI ecosystem.

It bridges the gap between:

AI Models ↔ Real-World Systems

By providing a standardized way for LLMs to communicate with APIs, databases, files, and business applications, MCP enables developers to build smarter, more capable AI-powered solutions.

If you're building AI applications in 2026 and beyond, understanding MCP is no longer optional—it's quickly becoming a core skill for modern developers.

Final Thoughts

The future of AI isn't just about smarter models—it's about smarter integrations.

MCP is helping transform AI from a standalone assistant into a connected system that can access data, execute actions, and solve real business problems.

If you're working with AI agents, automation, or enterprise applications, now is the perfect time to start exploring MCP.

Have you used MCP in your projects yet? Share your experience in the comments! 🚀

I Tested Claude Fable 5 for Coding, Research, and Long-Running Tasks — Here's What I Found

Himanshu Gupta — Wed, 10 Jun 2026 06:26:01 +0000

Artificial intelligence models are improving at an incredible pace, but the real question isn't benchmark scores—it's whether they help developers solve real problems faster.

Recently, I spent several days testing Claude Fable 5 across coding, documentation, debugging, research, and workflow automation tasks. In this article, I'll share what worked, what didn't, and where the model stands compared to previous AI assistants.

Why I Wanted to Test Claude Fable 5

Most AI model announcements focus on benchmarks and performance metrics. As a developer, I'm more interested in practical questions:

Can it write production-ready code?
Can it debug complex issues?
Can it maintain context across long conversations?
Can it help with technical documentation?
Can it automate repetitive tasks?

To answer these questions, I created several real-world test scenarios.

Test 1: Building a REST API

The first challenge was creating a simple REST API with authentication, validation, and database integration.

Prompt
Build a Node.js REST API using Express and PostgreSQL.
Include:

JWT authentication
User registration
Input validation
Error handling Result

Claude Fable 5 generated a well-structured project with:

Clean folder organization
Middleware separation
Proper validation
Clear documentation

What impressed me most was its ability to explain architectural decisions instead of simply generating code.

Test 2: Debugging Existing Code

Next, I provided a broken API endpoint containing multiple bugs.

Instead of suggesting random fixes, the model:

Identified the root cause.
Explained why the error occurred.
Proposed multiple solutions.
Highlighted potential side effects.

This felt closer to working with an experienced developer than using a code generator.

Test 3: Technical Documentation

Documentation is one of the most overlooked areas of software development.

I provided:

Source code
API endpoints
Configuration files

Claude Fable 5 generated:

API documentation
Setup instructions
Usage examples
Troubleshooting sections

The output required minor editing before publication but saved significant time.

Where Claude Fable 5 Performs Best

After multiple tests, these appear to be its strongest areas:

Software Engineering
Code generation
Refactoring
Debugging
Architecture discussions
Research
Summarizing technical papers
Comparing technologies
Creating implementation plans
Long Context Tasks

The model maintained context better than many previous-generation assistants when working through larger projects.

Limitations

No AI model is perfect.

I noticed occasional issues with:

Library version assumptions
Edge-case handling
Overconfident explanations

As always, generated code should be reviewed before production use.

Final Verdict

Claude Fable 5 feels less like a chatbot and more like a development assistant.

Its biggest strength isn't generating code—it's helping developers think through problems, understand trade-offs, and move faster without losing context.

For developers working on complex projects, documentation, or research-heavy workflows, Claude Fable 5 is worth exploring.

SEO-friendly DEV title alternatives:

I Tested Claude Fable 5 for a Week — My Honest Developer Review
Claude Fable 5 vs Previous AI Models: A Developer's Perspective
Building Real Projects with Claude Fable 5: What Works and What Doesn't
Why Claude Fable 5 Could Become Every Developer's AI Assistant
Claude Fable 5 Review: Coding, Debugging, and Research Benchmarks

AI Wrote the Code in 30 Seconds. I Spent 5 Hours Debugging It.

Himanshu Gupta — Mon, 01 Jun 2026 08:42:49 +0000

Three lines.

A simple function.

I prompted AI, it generated the code, I copied it, and it looked fine.

Clean syntax. Good variable names. No obvious errors.

Then I spent the next five hours debugging it.

The bug wasn't in the logic.

The AI had made a quiet assumption: a list would never be empty.

It worked 99% of the time.

The 1% crashed in production.

A real user.

A real failure.

A very real five hours of my life.

30 seconds of generation. Five hours of debugging.

That's not efficiency.

That's a trade-off nobody is talking about.

This isn't an anti-AI article.

I use AI every single day.

It has genuinely changed how I work.

But I've stopped pretending that speed at write time is the only metric that matters.

Here's what I've learned about the hidden cost of AI-generated code after paying that cost enough times to notice the pattern.

The Myth of Fast Code

We've been sold a simple story:

AI makes you faster. Prompt. Copy. Ship. Repeat.

And it's true.

The writing is faster.

Dramatically faster.

What used to take an hour now takes minutes.

That part is real.

But the story always stops there.

It doesn't mention what happens after.

The AI writes the code in seconds.

You ship it.

You move on.

Weeks later, a bug surfaces.

Subtle.

Hard to reproduce.

Buried in code you didn't write and don't fully own.

Now you're not debugging logic you understand.

You're reverse-engineering code from a system that can't explain its own assumptions.

You're reading it like a stranger's handwriting, trying to figure out what they meant.

The fast code isn't free.

It's borrowed time.

The debt shows up later—and by then you've completely forgotten what the AI assumed when it wrote it.

Three Times AI Code Cost Me More Than It Saved

1. The Invisible Assumption (5 Hours)

The AI assumed a list would never be empty.

Didn't check.

Didn't add a guard.

Why would it?

It only knows what I asked—not what real users actually do.

The bug showed up in production two weeks later.

A user with zero data hit the flow.

The whole thing crashed.

The fix?

One line.

if not items:
    return []

The debugging?

Five hours of confused, increasingly frustrated me:

Tracing logs
Adding print statements
Reproducing environments
Questioning my own sanity

All to find a single missing assumption.

Metric	Time
⚡ Saved at write time	5 minutes
🔥 Cost at debug time	5 hours

Ratio: 60x

2. The "Works on My Machine" Trap (1 Full Day)

The AI-generated code passed every test.

It ran perfectly locally.

I was confident.

So I shipped it.

Production had other ideas.

The AI optimized for:

Clean inputs
Predictable fixtures
Happy-path scenarios

It never considered:

Dirty data
Missing fields
Legacy records
Weird user behavior

I spent an entire day chasing a bug that only existed in the wild.

Metric	Time
⚡ Saved at write time	10 minutes
🔥 Cost at debug time	1 full day

3. The Naming Trap (3 Hours)

The AI named a variable:

data

Technically valid.

Completely useless.

Three months later I had no clue what it represented.

Was it:

Raw user input?
Transformed output?
Cached database results?
Filtered records?

Nobody knew.

Including me.

I spent three hours tracing execution paths that should have taken ten minutes to understand.

The AI optimized for convenience.

I paid for it later.

Metric	Time
⚡ Saved at write time	0 minutes
🔥 Cost at debug time	3 hours

What AI Code Actually Costs

The biggest costs aren't measured in hours.

They're measured in something harder to quantify.

Cognitive Load

You didn't write the code.

So you don't have the mental model.

Every time you revisit it, you're forced to rebuild your understanding from scratch.

It's like returning to a codebase you've never seen before.

Except you're supposedly the author.

Confidence Erosion

After enough "works on my machine" moments, something changes.

You stop trusting your own testing.

You start shipping with low-grade anxiety.

You add logs "just in case."

You write extra tests not because the code needs them—but because you don't trust code you didn't truly create.

The "Just In Case" Spiral

Extra validation.

Extra checks.

Extra error handling.

Not because requirements demand it.

Because uncertainty does.

Those little defensive additions slowly consume hours.

One tiny safeguard at a time.

Opportunity Cost

Every hour spent debugging AI-generated code is an hour not spent on:

Architecture
Product decisions
Performance improvements
Customer problems
Strategic work

The work that actually benefits from your experience.

Why These Costs Stay Invisible

No Jira ticket tracks them.

No dashboard reports them.

No sprint retrospective highlights them.

They're scattered across dozens of tiny debugging sessions.

Five minutes here.

An hour there.

Half a day somewhere else.

Individually small.

Collectively enormous.

One day you wake up and realize:

Debugging has become the actual job.

What I'm Doing Differently

I'm not quitting AI.

That ship has sailed.

And honestly, I don't want it back.

But I've changed how I use it.

1. I Don't Ship Code I Can't Explain

If I can't walk through the logic line by line, I don't ship it.

Even if every test passes.

Even if the AI sounds confident.

Understanding comes before deployment.

2. I Treat AI Output as a First Draft

The AI writes the structure.

I rewrite the important parts:

Edge cases
Variable names
Error handling
Business logic
Assumptions

It's slower.

But it's code I actually own.

3. I Explicitly Look for Missing Assumptions

AI naturally optimizes for happy paths.

So I immediately ask:

What happens if input is empty?
What if it's null?
What if it's malformed?
What if the API returns something unexpected?

Then I add those checks myself.

Every time.

4. I Budget a Debugging Tax

Every AI-generated function gets an extra review budget.

Roughly 30 minutes.

Not because I'm pessimistic.

Because I've seen the pattern enough times.

That tax usually pays for itself before production ever sees the bug.

The Honest Trade-Off

AI code is usually:

Faster to write.

But often:

Slower to debug.

The ratio varies.

Sometimes it's 2x.

Sometimes it's 20x.

Sometimes it's that painful 60x that makes you question your life choices.

The question was never:

Is AI good or bad?

That's the wrong debate.

The real question is:

What is the ratio for your work, your codebase, and your team?

For throwaway scripts?

Use AI and don't look back.

For prototypes?

Absolutely.

For core business logic that someone will be debugging at 2:00 AM six months from now?

Slow down.

Be deliberate.

Be present.

Because the trade-off is real.

And pretending it doesn't exist doesn't make it disappear.

It just means you'll discover it in production instead of before it.

Final Thought

AI isn't replacing engineering judgment.

It's making engineering judgment more valuable.

The fastest code is not the code that gets written first.

The fastest code is the code that doesn't cost you five hours later.

One Question 👇

What's your worst "AI wrote it fast, I debugged it slow" story?

⏱️ How long did the bug take to find?
🤖 What assumption did AI make?
💡 What lesson did you learn?

Mine: A single missing if statement caused an empty-list crash in production. Cost me 5 hours to find.

Your turn. 👇 Share your story! 🚀

How Login Jails Can Dramatically Improve Your Application Security

Himanshu Gupta — Sat, 30 May 2026 07:43:50 +0000

Authentication is the first line of defense for any application. While implementing username/password authentication is straightforward, protecting login endpoints from brute-force attacks is equally important. One effective approach is introducing jail features into your login system.

In this article, we'll explore what login jails are, why they matter, and how they can significantly improve application security.

What Is a Login Jail?

A login jail is a security mechanism that temporarily restricts or blocks access when suspicious login activity is detected. The concept is commonly used in tools such as Fail2Ban, where repeated failed login attempts trigger automatic protection rules.

The goal is simple: prevent attackers from repeatedly guessing passwords while allowing legitimate users to continue accessing the system.

Why Login Jails Matter

Without protection, attackers can automate thousands of login attempts within minutes. This can lead to:

Account compromise
Credential stuffing attacks
Increased server load
Unauthorized access to sensitive data

A login jail mitigates these risks by limiting repeated authentication failures.

Key Jail Features for Modern Login Systems

1. Failed Login Attempt Tracking

Track the number of unsuccessful login attempts for each user or IP address.

Example:

1–4 failed attempts → Allow retries
5th failed attempt → Trigger security action

2. Temporary Account Lockout

Temporarily lock the account after a defined number of failed attempts.

Benefits:

Prevents brute-force attacks
Gives users time to verify suspicious activity
Reduces automated attack effectiveness

3. IP Address Blocking

Block IP addresses that repeatedly attempt invalid logins.

Example Rules:

10 failed attempts within 5 minutes → Block IP for 30 minutes

4. Progressive Delays

Instead of immediately locking users out, introduce increasing delays between login attempts.

Failed Attempts	Delay
3	10 seconds
5	30 seconds
7	2 minutes
10	Temporary lock

This approach improves security while maintaining a better user experience.

5. CAPTCHA Verification

Display a CAPTCHA after multiple failed login attempts.

This helps distinguish between:

Human users
Automated bots

6. Security Notifications

Notify users whenever unusual login activity occurs.

Examples:

Multiple failed login attempts
Login from a new device
Login from a different location

Notifications can be sent via email, SMS, or push notifications.

7. Audit Logging

Maintain detailed security logs for monitoring and investigation.

Log information such as:

Timestamp
Username
IP address
Device information
Login result

These logs help identify attack patterns and support compliance requirements.

8. Whitelisting Trusted Sources

Allow administrators to whitelist:

Corporate networks
Internal systems
Trusted devices

This prevents accidental lockouts while preserving security controls.

9. Multi-Factor Authentication (MFA)

A login jail becomes significantly more effective when combined with MFA.

Even if an attacker obtains valid credentials, they still need:

An authenticator app code
A security key
Email or SMS verification

10. Automatic Jail Release

Users should regain access automatically after the lockout period expires.

Benefits:

Reduced support requests
Better user experience
Lower administrative overhead

Sample Login Jail Workflow

User attempts login
        |
        v
Password incorrect?
        |
       Yes
        |
Increment failure counter
        |
Failures >= Threshold?
        |
       Yes
        |
Apply Jail Rules
 ├─ Delay
 ├─ CAPTCHA
 ├─ IP Block
 └─ Account Lock

Best Practices

✅ Use both account-based and IP-based protection

✅ Avoid permanent lockouts

✅ Provide clear error messages without revealing sensitive information

✅ Combine jail mechanisms with MFA

✅ Monitor logs regularly

✅ Review thresholds based on application traffic

Conclusion

A secure login system is more than just authentication — it requires proactive protection against abuse. Implementing jail features such as failed-attempt tracking, temporary lockouts, IP blocking, CAPTCHA verification, and security notifications can dramatically reduce the risk of brute-force attacks.

By combining these protections with modern authentication practices like Multi-Factor Authentication, developers can create login systems that are both secure and user-friendly.

Security is not a single feature; it's a layered strategy. Login jails are one of the most effective layers you can add to your authentication workflow.

Default Nginx Is Dead? Here’s What’s Replacing It

Himanshu Gupta — Tue, 26 May 2026 16:43:57 +0000

For years, NGINX has been the default choice for reverse proxying and load balancing.

It solved massive scalability problems long before “cloud-native” became a buzzword.

But modern infrastructure is changing fast — and the traditional NGINX setup is starting to show its age.

The question is no longer:

“Can NGINX handle traffic?”

It absolutely can.

The real question is:

“Is file-based infrastructure management still the best approach in 2026?”

Why NGINX Became So Popular

Originally, NGINX became famous for solving the C10K problem — handling 10,000 concurrent connections efficiently on a single server.

Instead of creating a thread per request, it used an asynchronous event-driven architecture, which made it incredibly lightweight and scalable.

Typical setup:

Users → NGINX → Multiple Backend Servers

NGINX handled:

Reverse proxying
Load balancing
SSL termination
Caching
Traffic distribution

And honestly? It still does all of this extremely well.

The Core Problem With Traditional NGINX

The issue isn’t performance.

The issue is configuration architecture.

Most NGINX setups still rely heavily on:

nginx.conf

This means:

Manual upstream configuration
Static server definitions
Reloads/restarts for changes
Infrastructure tightly coupled to config files

Example:

upstream backend {
    server app1:8080;
    server app2:8080;
    server app3:8080;
}

This worked perfectly in static environments.

But modern systems are no longer static.

Today’s Infrastructure Is Dynamic

In Kubernetes and cloud-native environments:

Containers start and die constantly
IP addresses change dynamically
Services auto-scale every minute
Multi-region deployments are common
Traffic routing becomes programmable

A static config file starts becoming a bottleneck.

That’s why newer systems are moving toward:

Dynamic service discovery
API-driven configuration
Real-time traffic management
Control-plane/data-plane separation

So What’s Replacing Traditional NGINX?

Not necessarily replacing — evolving beyond it.

Modern alternatives include:

Envoy Proxy
Traefik
HAProxy
Caddy

But the biggest shift is architectural.

Instead of:

Static Config → Reload Server

We now have:

Dynamic Control Plane → Real-Time Updates

This is exactly why tools like Envoy became foundational in service mesh ecosystems such as:

Istio
Linkerd

Why Developers Are Moving Away From “Default NGINX”

Because modern systems demand:

1. Dynamic Configuration

No more manually editing files every time infrastructure changes.

2. Better Cloud-Native Integration

Kubernetes-native proxies understand services, pods, and scaling automatically.

3. Advanced Traffic Control

Things like:

Canary deployments
Rate limiting
Circuit breaking
Observability
Distributed tracing

are now first-class requirements.

4. API-Driven Infrastructure

Modern infra is becoming programmable.

Not manually configured.

Is NGINX Actually Dead?

Not even close.

Huge companies still use NGINX at scale.

But “default NGINX everywhere” is slowly fading.

The industry is shifting toward:

Dynamic proxies
Cloud-native networking
Service meshes
API-first infrastructure

NGINX is no longer the only serious option.

And for many modern architectures, it’s no longer the most flexible one either.

Final Thoughts

NGINX solved the internet’s scaling problems for years.

But infrastructure evolved.

Today’s systems need:

Real-time adaptability
Dynamic discovery
Programmable networking
Cloud-native traffic management

The future isn’t about replacing NGINX.

It’s about moving beyond static infrastructure.

And that shift is already happening.

Hoisting in JavaScript | Episode 3

Himanshu Gupta — Mon, 12 Jan 2026 06:08:27 +0000

🔍 What is Hoisting?

Hoisting is a JavaScript mechanism where variable and function declarations are moved to the top of their scope during the memory creation phase of the execution context.

⚠️ Only declarations are hoisted, not initializations.

🧠 How Hoisting Works

JavaScript code runs in two phases:
Memory Creation Phase
Code Execution Phase
During the memory creation phase:
Variables declared using var are initialized with undefined
Function declarations are stored in memory as they are
This allows:
Variables to be accessed before assignment
Functions to be called before declaration
Accessing a variable before assigning a value returns undefined
Accessing a variable that is not declared at all throws a ReferenceError

Variable declarations → undefined Function declarations → fully available

📌 Hoisting Behavior Summary
| Declaration Type | Hoisted | Initial Value |
| -------------------- | ---------- | ------------- |
| var variable | ✅ Yes | undefined |
| Function declaration | ✅ Yes | Full function |
| Function expression | ⚠️ Partial | undefined |
| Arrow function | ⚠️ Partial | undefined |
| Undeclared variable | ❌ No | Error |

✅ Example 1: Variable & Function Hoisting
`getName(); // Namaste Javascript
console.log(x); // undefined

var x = 7;

function getName() {
console.log("Namaste Javascript");
}`

Explanation

getName() is fully hoisted and can be called before declaration
x is hoisted and initialized with undefined
No error occurs

❌ Example 2: Accessing an Undeclared Variable
`getName(); // Namaste JavaScript
console.log(x); // ReferenceError: x is not defined
console.log(getName); // function getName() {...}

function getName() {
console.log("Namaste JavaScript");
}
`

Explanation

x is never declared
JavaScript throws a ReferenceError
Function declarations are still hoisted correctly

❌ Example 3: Function Expression Hoisting

`getName(); // TypeError: getName is not a function
console.log(getName); // undefined

var getName = function () {
console.log("Namaste JavaScript");
};
`

Explanation

-Function expressions behave like variables
-getName is hoisted as undefined
-Calling it as a function throws a TypeError

Interpreter vs Compiler: What’s the Difference?

Himanshu Gupta — Sun, 04 Jan 2026 16:00:18 +0000

🧠 Interpreter vs Compiler – What’s the Difference?

When we write code, the computer does not understand it directly.

Computers only understand machine language (0s and 1s).

So, programming languages use translators to convert human-readable code into machine-readable code.

There are two main types of translators:

Interpreter
Compiler

Let’s understand both in a very simple way 👇

🔍 What is an Interpreter?

An interpreter reads and executes code line by line.

How it works:

Reads one line of code
Converts it to machine language
Executes it
Moves to the next line

If an error occurs, the program stops immediately.

::contentReference[oaicite:0]{index=0}

✅ Key Points of Interpreter

Executes code line by line
Slower execution
Stops at the first error
No executable file is created

🧑‍💻 Languages That Use Interpreter

JavaScript
Python
PHP
Ruby

Example (JavaScript):


js
console.log("Hello");
console.log(a); // error
console.log("World"); // this will not run

Converting a Monolithic App to Microservice-Based Architecture

Himanshu Gupta — Sun, 14 Dec 2025 09:55:57 +0000

Summary: Converting a Monolithic App to Microservice-Based Architecture

This Blog focuses on the challenges and practical approach to converting a monolithic application into a microservice-based architecture, especially from the perspective of scalability, security, and efficient client consumption. The presenter uses Instagram as a real-world example to explain the concepts clearly.

Core Concepts and Challenges

Monolithic App Issues:
- Difficult to scale individual modules (e.g., Likes, Comments).
- Increasing server and database resources for one feature impacts the entire app and increases cost unnecessarily.
- Large teams face dependency conflicts, risking downtime if one component fails.
Naïve Microservice Approach:
- Simply splitting models (e.g., Authentication, Posts, Comments) into separate microservices and deploying them on different servers is not sufficient.
- The real challenge lies in:
- Ensuring security of each microservice.
- Implementing rate limiting to prevent abuse.
- Managing inter-service communication.
- Handling client consumption efficiently without exposing internal services.

Practical Implementation Steps

Division of Services:
- Split the monolithic app into smaller services (Auth, Users, Posts, Comments, Likes, Notifications).
- Each microservice may even use different types of databases based on needs (e.g., Redis for Auth, NoSQL for Posts).
Client Consumption Problem:
- Clients (mobile or web apps) require aggregated data from multiple services (e.g., user info, posts, comments).
- Hitting each microservice individually from the client is inefficient and insecure.
- Rate limiting and authentication become difficult when multiple endpoints are exposed.
API Gateway as a Central Entry Point:
- Introduce an API Gateway that acts as the single public endpoint.
- Clients only know and access the API Gateway, not individual microservices.
- The gateway routes requests internally to the right microservice based on URL paths or request type.
- All rate limiting, authentication, and security checks are implemented here.
Token-Based Authentication:
- Use JWT tokens to authenticate users.
- When a user logs in, the auth service issues a token.
- The API Gateway verifies this token on every request.
- After verification, the gateway injects user details (e.g., user ID) as headers before forwarding requests to microservices.
- This avoids each microservice needing to verify tokens independently.
Security Measures:
- Use asymmetric encryption (RSA algorithm) for JWT token signing:
- Private key used to sign tokens.
- Public key shared to verify tokens, enhancing security.
- Microservices accept requests only from the API Gateway (inbound network rules).
- Prevent direct access to microservices from outside sources.

Technology Choices (Not Prescriptive)

API Gateway can be provided by cloud platforms (AWS, etc.) or custom-built.
Backend server implementations can use Node.js, Go, Rust, or any preferred language based on team expertise and performance needs.
The presenter prefers Fastify on Node.js for speed but acknowledges alternatives.

Summary Table: Key Components and Their Roles

Component	Role/Function
Monolithic App	Single large app where all features are tightly coupled
Microservices	Small, independent services (Auth, Posts, Comments, Likes) with own databases
API Gateway	Single public endpoint that routes, authenticates, rate-limits, and aggregates microservice calls
JWT Tokens	Used for authenticating users and passing user info securely
RSA Algorithm	Used for signing/verifying tokens with private/public key pair
Security Rules	Restrict microservice access to only API Gateway; prevent direct external hits

Key Insights

Simply splitting a monolithic app into microservices is not enough; the architecture must ensure security, scalability, and efficient client interaction.
An API Gateway is essential to hide internal microservices and manage requests, authentication, and rate limiting centrally.
JWT with RSA encryption provides secure, scalable authentication across microservices without sharing secret keys.
Network-level security (inbound/outbound rules) is critical to restrict access among services and prevent unauthorized use.
This architecture improves scalability (e.g., scale only “likes” service if needed), reduces costs, and allows larger teams to work independently without causing system-wide failures.

Conclusion

The Blog offers a practical and structured approach to microservice migration from a monolithic app using real-world examples and best practices. It highlights security, efficient client consumption, and scalability as core pillars of modern microservice architecture. The presenter encourages feedback and further discussion on the topic.