API Security in Node.js and Express

Imagine AQAD becomes one of the largest B2B marketplaces in the region.

Thousands of vendors are listing products.

Thousands of retailers are placing orders.

Node.js Backend Architecture API Security, Rate Limiting, Redis Caching

Millions of rupees worth of transactions happen every day.

The platform stores:

Vendor information
Retailer information
Product inventory
Orders
Payment records
Delivery information
Business documents

Everything looks perfect.

Then one morning the support team receives several complaints.

A vendor says:

"My product prices were changed."

A retailer says:

"I can see another retailer's orders."

A finance manager says:

"Someone is trying thousands of login attempts every minute."

Now the question is no longer:

"How do we build features?"

The question becomes:

"How do we protect them?"

This is where API security becomes critical.

A backend without security is like a warehouse without locks, guards, cameras, or access control.

Eventually someone will exploit it.

Professional backend developers must think about security from the very beginning.

Not after an attack happens.

In this chapter, we will learn how to secure Node.js and Express applications using real-world concepts, practical examples, and AQAD scenarios.

What Is API Security?

API Security is the process of protecting backend services from:

Unauthorized access

Data theft

Data manipulation

Malicious users

Automated attacks

System abuse

Security vulnerabilities

The goal is simple:

Allow legitimate users.

Block malicious users.

Protect sensitive data.

Real World Analogy: Securing a Warehouse

Imagine AQAD owns a giant warehouse.

Would you allow anyone to enter?

Of course not.

The warehouse would have:

Security guards

Identity checks

Access cards

Restricted areas

Security cameras

Visitor logs

Emergency procedures

API security works exactly the same way.

Your backend becomes the warehouse.

Users become visitors.

Endpoints become restricted rooms.

Authentication becomes identity verification.

Authorization becomes access control.

Logging becomes security cameras.

Why Security Matters

Many developers believe:

"Nobody will attack my application."

Unfortunately, attackers don't care whether your application is large or small.

Automated bots constantly scan the internet searching for vulnerabilities.

Common targets include:

Public APIs

File uploads

Payment systems

Admin panels

User accounts

Every exposed endpoint becomes a potential target.

Common Security Threats

Before learning protection techniques, we must understand common threats.

Threat 1: Unauthorized Access

Imagine a retailer accesses:

/api/vendors

and receives all vendor information.

Or:

/api/orders

and receives orders belonging to other companies.

This is a security failure.

Sensitive information must be protected.

Threat 2: Stolen Accounts

Attackers often try:

admin
123456
password
admin123

Thousands of times.

This is called a brute-force attack.

Without protection:

Accounts can be compromised.

Threat 3: Data Manipulation

Imagine a retailer modifies a request.

Original:

{
  "quantity": 10
}

Modified:

{
  "quantity": -1000
}

Without validation:

Inventory calculations may break.

Financial reports become inaccurate.

Threat 4: Information Disclosure

Sometimes developers accidentally expose:

Database errors

Internal server paths

Secrets

Tokens

Environment variables

Example:

{
  "error": "MySQL connection failed at localhost:3306"
}

Attackers love this information.

Security Layer 1: Authentication

Authentication answers:

"Who are you?"

Users must prove their identity.

AQAD Example:

Vendor login:

{
  "email": "vendor@aqad.com",
  "password": "******"
}

If credentials are correct:

Access granted.

Otherwise:

Access denied.

Security Layer 2: Authorization

Authentication and authorization are different.

Authentication:

Who are you?

Authorization:

What can you do?

AQAD Example:

Vendor can:

Create products

Update products

View own orders

Retailer can:

Browse products

Place orders

Track orders

Delivery partner can:

View assigned deliveries

Update delivery status

Different users have different permissions.

Security Layer 3: Input Validation

Never trust user input.

Ever.

A professional developer assumes every request may be malicious.

Example:

{
  "email": ""
}

{
  "quantity": -100
}

{
  "price": "free"
}

Validation prevents invalid data from entering the system.

This is why we learned Joi and Express Validator earlier.

SQL Injection

One of the oldest attacks in web development.

Imagine a login query:

SELECT *
FROM users
WHERE email = 'abc'
AND password = '123'

An attacker attempts:

' OR 1=1 --

Result:

The database may return unexpected records.

The attacker may bypass authentication.

Why SQL Injection Happens

Developers directly combine user input with database queries.

Bad Example:

const query =
"SELECT * FROM users WHERE email = '" +
email + "'";

Dangerous.

Never trust user input.

Always use parameterized queries.

Safe Example

connection.query(
   "SELECT * FROM users WHERE email = ?",
   [email]
);

The database safely handles the input.

This significantly reduces risk.

AQAD Example

Retailer searches:

Pepsi

Attacker searches:

' DROP TABLE products;

Without protection:

Catastrophic damage may occur.

Parameterized queries prevent this.

NoSQL Injection

Node.js applications often use:

MongoDB

DynamoDB

Document databases

These databases are not immune.

Example malicious input:

{
  "email": {
    "$ne": null
  }
}

Improper validation can create security issues.

Input validation remains essential.

Cross Site Scripting (XSS)

Imagine a vendor submits:

<script>
alert("Hacked")
</script>

as a product description.

If the frontend renders this script:

The attacker's code executes.

Possible consequences:

Session theft

Account compromise

Malicious redirects

User tracking

Preventing XSS

Validate input.

Sanitize data.

Escape HTML content.

Never blindly render user-generated content.

Treat all user input as untrusted.

Cross Site Request Forgery (CSRF)

Imagine a retailer is logged into AQAD.

An attacker tricks the retailer into visiting a malicious website.

That website secretly sends requests to AQAD.

Without protection:

Unauthorized actions may occur.

Examples:

Order creation

Password changes

Profile updates

Payment actions

CSRF protection mechanisms help prevent this.

HTTPS: The First Line of Defense

Imagine sending login credentials through public Wi-Fi.

Without HTTPS:

Data travels in plain text.

Attackers may intercept it.

With HTTPS:

Data becomes encrypted.

Example:

http://example.com

Not secure.

Preferred:

https://example.com

Always use HTTPS in production.

Always.

JWT Security Best Practices

JWT is powerful.

But poor implementation creates vulnerabilities.

Never store secrets inside payloads.

Bad:

{
  "password": "123456"
}

Anyone can decode JWT payloads.

Store only necessary information.

Example:

{
  "userId": 101,
  "role": "vendor"
}

Much safer.

Strong JWT Secrets

Weak Secret:

secret123

Strong Secret:

f8xP@92L#1vKz7WmQxR!

Use strong, unpredictable values.

Store them securely.

Environment Variables

Never hardcode secrets.

Bad:

const JWT_SECRET =
"secret123";

Instead:

const JWT_SECRET =
process.env.JWT_SECRET;

Store secrets in:

JWT_SECRET=VeryStrongSecret

Environment variables reduce exposure risk.

Protecting Sensitive Information

Never expose:

Passwords

Tokens

Database credentials

API keys

Internal IP addresses

Private documents

Bad API Response:

{
  "password": "abc123"
}

Never do this.

Security Headers

Browsers support security headers.

These headers provide additional protection.

Examples:

Content Security Policy

X-Frame-Options

X-Content-Type-Options

Referrer Policy

Professional applications often use:

npm install helmet

Helmet automatically adds many helpful security headers.

Using Helmet

Installation:

npm install helmet

Usage:

const helmet = require("helmet");

app.use(helmet());

One line.

Significant security improvements.

Understanding CORS

CORS stands for:

Cross-Origin Resource Sharing.

Imagine:

Frontend:

app.aqad.com

Backend:

api.aqad.com

Browsers restrict cross-origin requests by default.

CORS defines who is allowed to access the API.

Unsafe CORS

Bad:

origin: "*"

Everyone can access.

Not ideal for sensitive systems.

Better CORS

Example:

origin: [
  "https://app.aqad.com"
]

Only approved domains can access the API.

Much safer.

Rate Limiting Introduction

Imagine one user sends:

10 requests

Normal.

Another sends:

100,000 requests

Potential attack.

Rate limiting helps control abuse.

We will explore it deeply in the next chapter.

File Upload Security

File uploads create additional risks.

Attackers may upload:

Malware

Scripts

Huge files

Fake extensions

Always:

Validate file type

Validate file size

Restrict access

Store files securely

Scan suspicious files

Logging Security Events

Every security-related event should be logged.

Examples:

Failed logins

Password resets

Authorization failures

Token expiration

Suspicious requests

These logs help identify attacks early.

Principle of Least Privilege

A simple but powerful rule.

Users should receive only the permissions they need.

AQAD Example:

Retailer should not:

Delete vendors

Modify delivery assignments

Access finance records

Vendor should not:

Access retailer invoices

Manage platform administrators

Less access means lower risk.

AQAD Security Architecture

Let's design a secure request flow.

Retailer Request

↓

HTTPS

↓

Rate Limiter

↓

Helmet Security Headers

↓

CORS Validation

↓

Authentication Middleware

↓

Authorization Middleware

↓

Input Validation

↓

Controller

↓

Database

↓

Response

Every layer adds protection.

This is how enterprise systems are designed.

OWASP and Secure Development

Security professionals often reference:

OWASP

(Open Worldwide Application Security Project)

OWASP identifies common application vulnerabilities.

Popular examples:

Injection Attacks

Broken Authentication

Sensitive Data Exposure

Security Misconfiguration

Broken Access Control

Learning OWASP concepts is extremely valuable for backend developers.

Common Security Mistakes Beginners Make

Mistake 1

Trusting user input.

Never do this.

Mistake 2

Hardcoding secrets.

Use environment variables.

Mistake 3

Skipping authorization checks.

Very dangerous.

Mistake 4

Returning detailed database errors.

Leaks internal information.

Mistake 5

Ignoring HTTPS.

All production applications should use HTTPS.

Mistake 6

Using weak JWT secrets.

Easy to compromise.

Mistake 7

Allowing unrestricted file uploads.

Major security risk.

Mini Exercise

Imagine AQAD has:

Vendor Dashboard

Retailer Dashboard

Admin Dashboard

For each dashboard identify:

Who should access it?

What authentication is required?

What authorization rules are needed?

What data must remain private?

Think like a security architect.

Rate Limiting and API Protection

Imagine AQAD launches a major promotion.

Thousands of retailers log in.

Vendors upload hundreds of new products.

Orders start flowing rapidly.

Everything looks great.

Then suddenly the servers become slow.

Product pages stop loading.

Order placement starts failing.

The support team receives hundreds of complaints.

Developers begin investigating.

After checking logs, they discover something unexpected.

One user has sent:

150,000 requests

in a few minutes.

Another IP address is attempting:

50,000 login attempts

against vendor accounts.

A third source is repeatedly requesting:

/api/products

thousands of times every second.

The application is not failing because of legitimate users.

It is failing because the system is being abused.

This is exactly why rate limiting exists.

Rate limiting protects applications from excessive usage, malicious attacks, and accidental overload.

we will learn how professional backend systems protect APIs using rate limiting and traffic control strategies.

What Is Rate Limiting?

Rate limiting is a technique used to restrict how many requests a user can make within a specific time period.

Think of it as crowd control.

Without crowd control:

Everyone rushes through the entrance.

Chaos begins.

With crowd control:

People enter in an organized manner.

The system remains stable.

API rate limiting follows the same principle.

Real World Analogy: Toll Plaza

Imagine a highway toll plaza.

If 10 cars arrive every minute:

Everything works smoothly.

If 50,000 cars arrive simultaneously:

Traffic becomes impossible to manage.

The toll system introduces control mechanisms.

Some lanes.

Traffic management.

Vehicle limits.

API rate limiting works similarly.

The backend controls how much traffic each user can generate.

Why Rate Limiting Is Important

Without rate limiting:

Servers can become overloaded.

Databases can become overwhelmed.

Applications become unavailable.

Attackers can abuse endpoints.

Infrastructure costs increase.

User experience suffers.

Rate limiting protects both the application and legitimate users.

Common Situations Where Rate Limiting Is Needed

Professional applications apply rate limiting to:

OTP verification

Password reset

Registration

Product search

Order creation

Payment APIs

File uploads

Public APIs

Administrative operations

Some endpoints require stricter limits than others.

Understanding API Abuse

Not every request is legitimate.

Some requests are malicious.

Some are accidental.

Some are automated.

Let's examine common abuse scenarios.

Scenario 1: Brute Force Login Attack

Suppose an attacker attempts:

admin
admin123
password123
welcome123

repeatedly.

Thousands of combinations.

The goal:

Guess the user's password.

Without rate limiting:

Attack may continue indefinitely.

With rate limiting:

Attempts are restricted.

Attack becomes significantly less effective.

AQAD Example

Vendor login endpoint:

POST /api/auth/login

Normal retailer:

5 login attempts

Attacker:

5000 login attempts

Rate limiting blocks excessive requests.

Scenario 2: OTP Abuse

Suppose AQAD provides OTP verification.

Endpoint:

POST /api/send-otp

A malicious user repeatedly requests OTPs.

Result:

SMS costs increase.

Email services become overloaded.

Legitimate users suffer delays.

Rate limiting prevents abuse.

Scenario 3: Product Scraping

Imagine AQAD contains:

100,000 products.

A competitor creates a bot.

The bot requests:

/api/products?page=1
/api/products?page=2
/api/products?page=3

continuously.

The goal:

Copy the entire catalog.

Rate limiting slows down such activities.

Scenario 4: DDoS Attacks

DDoS means:

Distributed Denial of Service.

Large numbers of devices send traffic simultaneously.

Goal:

Overwhelm the application.

Make it unavailable.

While rate limiting alone cannot stop massive DDoS attacks, it provides an important defensive layer.

How Rate Limiting Works

The concept is simple.

The server tracks:

Who made the request.

How many requests were made.

When they were made.

If limits are exceeded:

Requests are blocked.

Example:

100 requests

allowed every:

15 minutes

Request 101:

Rejected.

Understanding Rate Limit Rules

A rate limit generally contains:

Time Window

Maximum Requests

Action When Limit Exceeds

Example:

100 requests
per
15 minutes

Meaning:

A user can make 100 requests.

After that:

Temporary block.

Introducing Express Rate Limit

One of the most popular Node.js solutions is:

express-rate-limit

Installation:

npm install express-rate-limit

Simple and effective.

Creating a Basic Rate Limiter

Example:

const rateLimit = require("express-rate-limit");

const limiter = rateLimit({

    windowMs: 15 * 60 * 1000,

    max: 100

});

Apply globally:

app.use(limiter);

Now every user receives:

100 requests every 15 minutes.

Understanding windowMs

Example:

windowMs: 15 * 60 * 1000

Meaning:

15 minutes.

Alternative examples:

1 minute

1 hour

24 hours

The time window depends on business requirements.

Understanding max

Example:

max: 100

Meaning:

Allow:

100 requests.

Request 101:

Blocked.

Custom Error Message

Professional APIs provide meaningful responses.

Example:

message:
"Too many requests. Please try again later."

Response:

{
  "message": "Too many requests. Please try again later."
}

Clear.

Professional.

User friendly.

Different Limits for Different Endpoints

Not all APIs require identical limits.

5 requests

Product search:

100 requests

Public catalog:

500 requests

Admin operations:

20 requests

Each endpoint receives limits based on risk level.

Login Protection

Example:

const loginLimiter = rateLimit({

    windowMs: 15 * 60 * 1000,

    max: 5

});

Apply:

app.use(
    "/api/login",
    loginLimiter
);

Only five attempts allowed.

Excellent protection against brute-force attacks.

AQAD Login Security

Vendor login:

Maximum:

5 attempts

After limit exceeded:

Temporary lock.

User message:

Too many login attempts.
Try again after 15 minutes.

Simple but effective.

OTP Protection

OTP endpoints are frequently abused.

Example:

const otpLimiter = rateLimit({

    windowMs: 10 * 60 * 1000,

    max: 3

});

Meaning:

Three OTP requests.

Every ten minutes.

Prevents excessive SMS and email costs.

Password Reset Protection

Password reset systems should also be protected.

Example:

3 requests
per
hour

This reduces abuse and spam.

Payment Endpoint Protection

Payment APIs are business critical.

AQAD Example:

POST /api/payments

Rate limiting protects against:

Repeated payment attempts.

Fraud.

Automation abuse.

Unexpected traffic spikes.

File Upload Protection

File uploads consume significant resources.

Suppose a malicious user uploads:

500 files

per minute.

Storage costs increase.

Bandwidth increases.

Server resources become strained.

Rate limiting protects upload endpoints.

Product Upload Protection

AQAD Example:

Vendor product upload API.

Limit:

50 products
per hour

This prevents:

Spam products.

Automated abuse.

Accidental bulk uploads.

IP Based Rate Limiting

Most rate limiting solutions track:

IP Address.

Example:

192.168.1.1

Each IP receives independent limits.

Simple and widely used.

User Based Rate Limiting

Large applications often go further.

Instead of limiting by IP:

Limit by user account.

Example:

Vendor A

100 requests

Vendor B

100 requests

This approach is more accurate for authenticated systems.

Global Rate Limiting

Protect entire application.

Example:

1000 requests
per hour

for every user.

Acts as a safety net.

Endpoint Specific Rate Limiting

Protect high-risk routes individually.

Examples:

OTP

Payment

Password Reset

Admin APIs

More granular.

More effective.

Burst Traffic vs Sustained Traffic

Not all traffic spikes are malicious.

Suppose AQAD launches a promotion.

Thousands of retailers visit simultaneously.

This is legitimate traffic.

Professional systems distinguish between:

Short bursts

and

Continuous abuse

Rate limiting policies should be carefully designed.

Logging Rate Limit Violations

Whenever limits are exceeded:

Log the event.

Example:

IP exceeded login limit

Vendor exceeded upload limit

These logs help identify abuse patterns.

Combining Rate Limiting with Authentication

Rate limiting works best when combined with:

Authentication

Authorization

Logging

Monitoring

Validation

No single protection layer is enough.

Security always relies on multiple layers.

Reverse Proxies and Rate Limiting

Production applications often sit behind:

Nginx

Load Balancers

CloudFront

API Gateways

These services can also perform rate limiting before requests reach Node.js.

This reduces server load.

Improves performance.

Enhances protection.

AQAD API Protection Architecture

Let's design a professional flow.

Request Arrives

↓

CloudFront

↓

Load Balancer

↓

Rate Limiter

↓

Helmet

↓

CORS Validation

↓

Authentication

↓

Authorization

↓

Validation

↓

Controller

↓

Database

↓

Response

Multiple protection layers work together.

This is how enterprise systems operate.

Rate Limiting Best Practices

Protect login endpoints.

Protect OTP endpoints.

Protect payment APIs.

Protect file uploads.

Use meaningful error messages.

Log blocked requests.

Monitor suspicious traffic.

Combine with authentication.

Review limits regularly.

Test under heavy traffic.

Common Mistakes Beginners Make

Mistake 1

No rate limiting at all.

Extremely risky.

Mistake 2

Using identical limits everywhere.

Different endpoints need different rules.

Mistake 3

Ignoring login protection.

Common security weakness.

Mistake 4

Not logging blocked requests.

Makes investigation difficult.

Mistake 5

Overly strict limits.

Can affect legitimate users.

Balance is important.

Mini Exercise

Imagine AQAD contains:

OTP API

Product Search API

Product Upload API

Payment API

Assign appropriate limits to each endpoint.

Think about:

Business risk

Traffic volume

Potential abuse

User experience

This exercise helps develop real-world architecture skills.

Caching and Redis Introduction

Imagine AQAD has become a successful marketplace.

Thousands of vendors have joined.

Thousands of retailers place orders every day.

The platform now contains:

100,000+ products
Thousands of categories
Millions of inventory records
Thousands of daily orders

Everything works perfectly.

Then one day the business team launches a massive promotion.

Thousands of retailers open the application at the same time.

Everyone starts searching for products.

Everyone opens product pages.

Everyone browses categories.

Everyone checks inventory.

Suddenly the backend starts slowing down.

Database CPU usage rises.

Response times increase.

Product pages take several seconds to load.

Users become frustrated.

Support tickets increase.

The database team investigates.

They discover something interesting.

The same product information is being requested thousands of times every minute.

For example:

Pepsi 330ml

is being fetched repeatedly.

Every request travels:

Application

↓

Database

↓

Application

↓

Database

↓

Application

↓

Database

again and again.

Even though the product information rarely changes.

This is exactly the problem caching solves.

Caching is one of the most powerful techniques used by modern applications to improve speed and reduce database load.

In this chapter, we will learn how caching works, why Redis is popular, and how systems like AQAD can use caching to scale efficiently.

What Is Caching?

Caching is the process of temporarily storing frequently used data in a fast location so it can be retrieved quickly.

Instead of repeatedly asking the database for the same information, the application retrieves it from the cache.

Think of caching as keeping commonly used items nearby.

Real World Analogy: Frequently Used Files on Your Desk

Imagine you work in an office.

Important files are stored in a large archive room.

Every time you need a file, you walk to the archive room.

Retrieve the file.

Return to your desk.

Repeat.

After doing this 100 times, you realize something.

Some files are used every day.

Instead of walking to the archive room repeatedly, you keep them on your desk.

Now access becomes almost instant.

The archive room is your database.

Your desk is the cache.

Caching simply keeps frequently used information closer to the application.

Why Databases Become Slow

Databases are extremely powerful.

However, every query requires work.

The database must:

Receive request.

Process query.

Locate records.

Read data.

Return response.

If thousands of users request the same data repeatedly, the database performs the same work over and over.

Example:

Product Details

requested:

50,000 times

per day.

Without caching:

Database handles all 50,000 requests.

With caching:

Database may only handle a few requests.

Huge difference.

Understanding Cache Hits and Cache Misses

Caching revolves around two important concepts.

Cache Hit

Requested data already exists in cache.

Application retrieves it immediately.

Example:

Product موجود in cache

Result:

Fast response.

No database query.

Cache Miss

Requested data is not available in cache.

Application must query database.

Example:

Product not found in cache

Result:

Database request occurs.

Data is then stored in cache for future requests.

Cache Flow

Let's understand the process.

Retailer requests product.

↓

Check Cache

↓

Data Found?

↓

Yes

↓

Return Data

↓

Query Database

↓

Store in Cache

↓

Return Data

This simple process dramatically improves performance.

Why Caching Improves Speed

Consider these approximate timings.

Database Query:

100ms

Cache Lookup:

1ms

Difference:

100x faster

This is why caching is heavily used in modern systems.

What Is Redis?

Redis stands for:

Remote Dictionary Server

Redis is an in-memory database.

Unlike traditional databases:

MySQL

PostgreSQL

MongoDB

which store data primarily on disk,

Redis stores data in memory.

Memory access is extremely fast.

This makes Redis ideal for caching.

Real World Analogy: Warehouse vs Reception Desk

Imagine AQAD's central warehouse.

The warehouse stores all products.

Huge storage.

Large capacity.

But retrieving items takes time.

Now imagine a reception desk.

Frequently requested items are kept nearby.

Employees access them instantly.

Warehouse:

Database.

Reception Desk:

Redis Cache.

This is why Redis improves performance.

Installing Redis

A Node.js application typically connects to a Redis server.

Example package:

npm install redis

Connection:

const { createClient } = require("redis");

const client = createClient();

await client.connect();

Now Node.js can interact with Redis.

Storing Data in Redis

Example:

await client.set(
    "product:101",
    JSON.stringify(product)
);

Meaning:

Store product information under a unique key.

Retrieving Data

Example:

const product =
await client.get("product:101");

Redis immediately returns the data.

No database query required.

Understanding Cache Keys

Every cached item needs a unique identifier.

Examples:

product:101

category:10

vendor:500

inventory:1001

Good key naming is extremely important.

AQAD Product Caching

Suppose retailer requests:

/api/products/101

Backend flow:

Check Redis

↓

Product Found?

↓

Yes

↓

Return Product

↓

Query Database

↓

Store Product in Redis

↓

Return Product

Future requests become significantly faster.

Cache Aside Pattern

The most common caching strategy is called:

Cache Aside Pattern

Flow:

Application checks cache first.

If data exists:

Return cached data.

If data does not exist:

Query database.

Store result in cache.

Return result.

Most Node.js applications use this pattern.

Example Flow

Retailer requests Pepsi product.

Redis:

No Data

Database queried.

Product returned.

Product stored in Redis.

Next retailer requests Pepsi.

Redis:

Data Found

Response becomes nearly instant.

Setting Expiration Time

Cached data should not live forever.

Redis allows expiration.

Example:

await client.setEx(
    "product:101",
    3600,
    JSON.stringify(product)
);

Meaning:

Store data.

Automatically remove after:

1 hour

This keeps cache fresh.

Why Expiration Matters

Imagine inventory changes.

Database:

100 units

Cache:

100 units

Vendor sells:

50 units

Database becomes:

50 units

Cache still shows:

100 units

This is stale data.

Expiration helps reduce this problem.

Cache Invalidation

One of the most important concepts in caching.

Whenever data changes:

Cache must be updated or removed.

Example:

Vendor updates product price.

Old cache:

₹100

Database:

₹120

Cache now contains incorrect information.

Solution:

Delete cache.

Example:

await client.del("product:101");

Next request rebuilds cache.

AQAD Inventory Caching

Inventory changes frequently.

Be careful.

Good candidates for caching:

Product details

Session Storage with Redis

Many applications store user sessions.

Without Redis:

Sessions may be stored in server memory.

Problem:

Server restart.

Sessions disappear.

Redis solves this problem.

Example:

User Session

stored inside Redis.

Benefits:

Fast.

Shared across servers.

Reliable.

Authentication and Redis

AQAD Example:

Vendor logs in.

Session stored in Redis.

Every request checks Redis.

Result:

Fast authentication.

Reduced database load.

Better scalability.

Rate Limiting with Redis

Remember Chapter 18?

Rate limiting requires tracking requests.

Redis is commonly used.

Example:

IP Address

↓

Request Count

Redis stores counters efficiently.

This makes rate limiting scalable.

Caching Categories

Categories rarely change.

AQAD Example:

Fresh Food

Beverages

Health & Beauty

Perfect caching candidates.

Large performance gains.

Minimal risk.

Caching Product Search Results

Suppose retailers repeatedly search:

Pepsi

Instead of querying database every time:

Store search results in Redis.

Future searches become faster.

Redis Data Structures

Redis supports multiple structures.

Strings

Lists

Sets

Hashes

Sorted Sets

Most caching scenarios initially use strings.

As applications grow, advanced structures become valuable.

Monitoring Cache Performance

Developers often track:

Cache Hits

Cache Misses

Cache Size

Memory Usage

Expiration Rates

High cache hit rates generally indicate efficient caching.

AQAD Performance Architecture

Without Cache:

Retailer Request

↓

Backend

↓

Database

↓

Response

Every request hits database.

With Cache:

Retailer Request

↓

Backend

↓

Redis

↓

Database (only when needed)

↓

Response

Database workload drops significantly.

Performance improves dramatically.

When Not To Use Caching

Beginners often try to cache everything.

This creates problems.

Avoid caching:

Highly dynamic data

Sensitive temporary data

Frequently changing information

Short-lived transactional states

Caching should be strategic.

Best Practices for Caching

Cache frequently requested data.

Use meaningful cache keys.

Set expiration times.

Monitor cache performance.

Invalidate stale data.

Do not cache everything.

Use Redis for production systems.

Test cache behavior thoroughly.

Understand data freshness requirements.

Combine caching with proper monitoring.

Common Mistakes Beginners Make

Mistake 1

Caching everything.

Creates stale data problems.

Mistake 2

No expiration time.

Old data remains forever.

Mistake 3

Poor key naming.

Creates confusion.

Mistake 4

Ignoring cache invalidation.

Causes incorrect responses.

Mistake 5

Assuming cache replaces database.

It does not.

Cache complements the database.

Mini Exercise

Imagine AQAD contains:

Product Details

Deployment – Taking Your Backend from Laptop to the Real World

The Day AQAD Was Ready

After months of development, the AQAD team finally completed a major milestone.

The backend was working perfectly.

Vendor registration worked.

Retailers could place orders.

Products could be uploaded.

JWT authentication worked.

Payments were integrated.

Redis caching was configured.

Everything looked amazing.

The developers gathered in the office.

One of them smiled and said:

"Great. AQAD is finished."

The team lead laughed.

"No. AQAD has only just begun."

Everyone looked confused.

The backend was complete.

The APIs were working.

The database was connected.

So what was missing?

The team lead opened his laptop and asked:

"Can a retailer in Dubai access your localhost?"

Silence.

Because all developers eventually learn one important lesson:

A project running on your laptop is not a product.

A project becomes a real application only when it is deployed.

This chapter is about that journey.

The journey from:

localhost:3000

api.aqad.com

accessible by thousands of users around the world.

What Is Deployment?

Deployment is the process of moving your application from a development environment to a production environment where real users can access it.

Think about building a restaurant.

Creating recipes is development.

Testing food with staff is testing.

Opening the restaurant to customers is deployment.

Similarly:

Writing code = Development

Testing code = QA

Making it available to users = Deployment

Deployment is where your application finally meets the real world.

Why Deployment Matters

Many beginners focus only on writing code.

Professional developers think differently.

They ask:

Can it scale?

Can it recover from failures?

Can it be monitored?

Can it be updated safely?

Can it remain secure?

Deployment answers these questions.

Development vs Production

Let's compare.

Development Environment

Purpose:

Build features.

Example:

localhost:3000

Characteristics:

Frequent changes

Debugging enabled

Console logs everywhere

Small datasets

Single developer

Production Environment

Purpose:

Serve real users.

Example:

api.aqad.com

Characteristics:

Stable

Secure

Monitored

Optimized

High availability

Real customer traffic

Real World Analogy: Test Kitchen vs Restaurant

Imagine AQAD owns a restaurant.

The chef experiments in a test kitchen.

Nobody sees mistakes.

Nobody complains.

That's development.

Now imagine opening the restaurant to paying customers.

Every dish matters.

Every mistake matters.

Every delay matters.

That is production.

Deployment is moving from the test kitchen to the restaurant.

Understanding Servers

When AQAD launches publicly, the backend needs a computer that runs 24/7.

This computer is called a server.

A server:

Receives requests.

Processes data.

Returns responses.

Stores application files.

Runs continuously.

Unlike your laptop:

Servers remain online day and night.

What Happens After Deployment?

Let's follow a retailer.

The retailer opens:

app.aqad.com

Browser sends request.

↓

Server receives request.

↓

Node.js processes request.

↓

Database queried.

↓

Response returned.

All this happens inside deployed infrastructure.

What Is a VPS?

VPS means:

Virtual Private Server.

Think of it as renting a computer on the internet.

Popular VPS providers:

DigitalOcean

Linode

Vultr

Advantages:

Affordable

Easy setup

Good for learning

Full server control

VPS Analogy

Imagine renting a small shop.

The shop belongs to the building owner.

But you control everything inside.

A VPS works similarly.

You rent computing resources.

You install your application.

You manage the environment.

AQAD's First Deployment

Imagine AQAD is still a startup.

Daily users:

Daily orders:

A VPS may be enough.

Backend:Node.js

Database:MySQL

Cache:Redis

All running on one server.

Simple.

Cost effective.

What Is Cloud Computing?

As AQAD grows:

200 users become:

20,000 users

One server may not be enough.

This is where cloud platforms help.

Popular providers include:

Amazon Web Services (AWS)

Microsoft Azure

Google Cloud Platform

Cloud computing allows applications to scale on demand.

Why Companies Love AWS

Imagine AQAD launches a festival sale.

Traffic increases:

10x

20x

50x

With traditional infrastructure:

Servers may crash.

With cloud infrastructure:

Resources can expand dynamically.

This is one reason AWS became popular.

Important AWS Services for Backend Developers

You do not need to learn all AWS services immediately.

Focus on the most important ones.

EC2

Think of EC2 as a virtual server.

Runs:

Node.js

Express

Redis

Applications

AQAD backend can run on EC2.

RDS

Managed database service.

Supports:

MySQL

PostgreSQL

MariaDB

Instead of managing database servers manually, AWS manages them.

S3

Object storage.

Perfect for:

Product Images

Vendor Documents

Invoices

Marketing Assets

AQAD product photos can live inside S3.

CloudFront

Content Delivery Network (CDN).

Makes content faster globally.

Useful for:

Images

Static files

Videos

Route 53

DNS management service.

Maps:

api.aqad.com

to your infrastructure.

What Is a Domain?

A domain is the address users type into a browser.

Example:

aqad.com

Without domains:

Users would need:

18.117.22.10

which is difficult to remember.

Domains make applications user-friendly.

What Is DNS?

DNS stands for:

Domain Name System.

Think of DNS as the internet's phonebook.

Example:

User enters:

api.aqad.com

DNS converts it into:

18.117.22.10

Server receives request.

Response returned.

This happens within milliseconds.

HTTPS and SSL Certificates

Imagine a retailer logs in.

Credentials:

{
  "email": "retailer@aqad.com",
  "password": "*******"
}

Without HTTPS:

Data may be intercepted.

With HTTPS:

Data becomes encrypted.

Users see:

🔒 Secure Connection

in the browser.

SSL certificates enable HTTPS.

Every production application should use HTTPS.

Always.

Environment Variables in Production

Remember this:

Never hardcode secrets.

Bad:

const JWT_SECRET = "mysecret";

Good:

const JWT_SECRET =
process.env.JWT_SECRET;

Production servers use:

JWT_SECRET=VeryStrongSecret
DB_PASSWORD=SecurePassword

This keeps sensitive data protected.

Process Managers

What happens if Node.js crashes?

Without protection:

Application stops.

Users cannot access AQAD.

Professional deployments use process managers.

Popular choice:

PM2

Installation:

npm install pm2 -g

Start application:

pm2 start server.js

Benefits:

Automatic restart

Monitoring

Log management

Process control

Real World Analogy: Backup Generator

Imagine a shopping mall.

Electricity fails.

Backup generator activates automatically.

Customers barely notice.

PM2 works similarly.

If Node.js crashes:

PM2 restarts it.

Service continues.

Logging in Production

Remember Chapter 15.

Logs become even more important after deployment.

Example:

Vendor Login Failed

Payment Gateway Timeout

Database Connection Lost

Production logs help diagnose issues quickly.

Without logs:

Finding problems becomes difficult.

Monitoring Production Systems

Deployment is not the finish line.

It is the starting line.

Applications must be monitored continuously.

Questions include:

Is CPU usage high?

Is memory usage increasing?

Are APIs slowing down?

Are users receiving errors?

Monitoring answers these questions.

AQAD Monitoring Example

Imagine:

Normal response time:

120ms

Suddenly:

4000ms

Monitoring tools detect the issue.

Developers investigate before customers complain.

CI/CD Explained

One of the most important modern concepts.

CI:

Continuous Integration

CD:

Continuous Deployment

Traditional Deployment

Developer writes code.

↓

Creates ZIP file.

↓

Uploads manually.

↓

Restarts server.

↓

Prays nothing breaks.

Not ideal.

CI/CD Deployment

Developer pushes code.

↓

Tests run automatically.

↓

Build created automatically.

↓

Deployment starts automatically.

↓

Production updated safely.

Much better.

Real World Analogy: Automated Factory

Imagine manufacturing products.

Manual process:

Slow.

Error-prone.

Automated factory:

Fast.

Consistent.

Reliable.

CI/CD works exactly the same way.

Popular CI/CD Tools

Examples:

GitHub Actions

GitLab CI/CD

Jenkins

These tools automate deployments.

AQAD Production Architecture

Let's imagine AQAD becomes a major marketplace.

Architecture:

Retailers

Vendors

↓

CloudFront

↓

Load Balancer

↓

Node.js Servers

↓

Redis Cache

↓

MySQL Database

↓

S3 Storage

↓

Monitoring & Logging

This resembles how many modern platforms operate.

High Availability

Imagine a server fails.

Without redundancy:

Application becomes unavailable.

With multiple servers:

Traffic moves automatically.

Users continue working.

This concept is called:

High Availability.

Enterprise systems depend on it.

Scaling Applications

As AQAD grows:

Users increase.

Orders increase.

Products increase.

Infrastructure must scale.

Scaling generally occurs in two ways.

Vertical Scaling

Bigger server.

More CPU.

More RAM.

Horizontal Scaling

More servers.

Traffic distributed across servers.

Large applications usually prefer horizontal scaling.

Deployment Best Practices

Use HTTPS.

Use environment variables.

Enable logging.

Enable monitoring.

Automate deployments.

Backup databases.

Use process managers.

Protect secrets.

Test before deployment.

Monitor after deployment.

Common Mistakes Beginners Make

Mistake 1

Deploying directly from local machine.

Mistake 2

Hardcoding secrets.

Mistake 3

Ignoring backups.

Mistake 4

No monitoring.

Mistake 5

No SSL certificate.

Mistake 6

No error logging.

Mistake 7

Manual deployment every time.

Mini Exercise

Imagine AQAD has:

10,000 retailers

2,000 vendors

100,000 products

Design a deployment architecture.

Think about:

Servers

Database

Storage

Caching

Monitoring

Security

Scalability

Try designing it like a real backend architect.

Node.js Backend Architecture: API Security, Rate Limiting, Redis Caching

API Security in Node.js and Express

What Is API Security?

Real World Analogy: Securing a Warehouse

Why Security Matters

Common Security Threats

Threat 1: Unauthorized Access

Threat 2: Stolen Accounts

Threat 3: Data Manipulation

Threat 4: Information Disclosure

Security Layer 1: Authentication

Security Layer 2: Authorization

Security Layer 3: Input Validation

SQL Injection

Why SQL Injection Happens

Safe Example

AQAD Example

NoSQL Injection

Cross Site Scripting (XSS)

Preventing XSS

Cross Site Request Forgery (CSRF)

HTTPS: The First Line of Defense

JWT Security Best Practices

Strong JWT Secrets

Environment Variables

Protecting Sensitive Information

Security Headers

Using Helmet

Understanding CORS

Unsafe CORS

Better CORS

Rate Limiting Introduction

File Upload Security

Logging Security Events

Principle of Least Privilege

AQAD Security Architecture

OWASP and Secure Development

Common Security Mistakes Beginners Make

Mini Exercise

Rate Limiting and API Protection

What Is Rate Limiting?

Real World Analogy: Toll Plaza

Why Rate Limiting Is Important

Common Situations Where Rate Limiting Is Needed

Understanding API Abuse

Scenario 1: Brute Force Login Attack

AQAD Example

Scenario 2: OTP Abuse

Scenario 3: Product Scraping

Scenario 4: DDoS Attacks

How Rate Limiting Works

Understanding Rate Limit Rules

Introducing Express Rate Limit

Creating a Basic Rate Limiter

Understanding windowMs

Understanding max

Custom Error Message

Different Limits for Different Endpoints

Login Protection

AQAD Login Security

OTP Protection

Password Reset Protection

Payment Endpoint Protection

File Upload Protection

Product Upload Protection

IP Based Rate Limiting

User Based Rate Limiting

Global Rate Limiting

Endpoint Specific Rate Limiting

Burst Traffic vs Sustained Traffic

Logging Rate Limit Violations

Combining Rate Limiting with Authentication

Reverse Proxies and Rate Limiting

AQAD API Protection Architecture

Rate Limiting Best Practices

Common Mistakes Beginners Make

Mini Exercise

Caching and Redis Introduction

What Is Caching?

Real World Analogy: Frequently Used Files on Your Desk