Web development has too many terms.

Frontend. Backend. API. Database. Server. Cookie. Session. JWT. OAuth. CORS. CSRF. XSS. REST. GraphQL. WebSocket. Cache. Load balancer. Reverse proxy. CDN. Deployment. Environment variable. Container. Queue.

If you learn these words one by one, they feel random.

But they are not random.

Most of them exist because every web application has to solve the same basic problems:

How does a user find the application?
How does the browser talk to the server?
How does the server find data?
How does the system know who the user is?
How does the system decide what the user can access?
How does the application stay fast?
How does it stay secure?
How does it scale when many people use it at once?
How does it get deployed without breaking everything?

This post explains modern web development using one large analogy:

A web application is like a large office building.

The analogy is not perfect. No analogy is.

But it is useful because most web systems are really about people, entrances, requests, permissions, records, routing, security, and scale.

That maps well to an office building.

The Big Picture

Imagine you are visiting a large company office.

You want to access a confidential document.

You do not walk straight into the archive room.

You go through a journey:

You find the building.
You enter through the front gate.
Reception talks to you.
Security checks who you are.
Your badge controls where you can go.
Employees process your request.
Records are fetched from storage.
Some records may already be cached nearby.
If the office is busy, traffic is distributed across multiple buildings.
Some requests are synchronous.
Some requests are asynchronous.
Some updates happen in real time.

That journey is very close to how a modern web application works.

A simplified web request looks like this:

User
  |
  v
Browser
  |
  v
Domain Name
  |
  v
DNS
  |
  v
Internet
  |
  v
Load Balancer / Reverse Proxy
  |
  v
Frontend / Backend
  |
  v
API
  |
  v
Application Logic
  |
  v
Cache / Database / External Services
  |
  v
Response

This is the whole story.

Everything else is detail.

Core Mapping

Web Concept	Office Building Analogy
User	Visitor
Browser	Visitor’s assistant
Domain name	Street address
DNS	Address lookup service
Server	Office building
Frontend	Reception desk
Backend	Employees and departments
API	Internal request form
Database	Filing room / records archive
Cache	Frequently used documents on a nearby desk
Authentication	Security guard checking identity
Authorization	Badge permissions
Session	Visitor record at security desk
Cookie	Small note kept by the visitor’s assistant
JWT	Signed visitor badge
OAuth	Trusted external identity provider
HTTPS	Sealed communication envelope
CORS	Approved caller policy
CSRF	Forged request using your valid identity
XSS	Malicious instruction inserted into office documents
REST	Standard request forms
GraphQL	Custom report request
Polling	Repeatedly asking if something is ready
Server-Sent Events	Office announcement system
WebSocket	Permanent phone line
Load Balancer	Traffic director
Reverse Proxy	Front gate
CDN	Regional document kiosk
Queue	Work inbox
Worker	Back-office employee processing queued work
Container	Portable office room
Environment	Branch office: dev, staging, production
Deployment	Opening a new version of the office

Keep this table in mind.

Now we can walk through the whole system step by step.

Part 1: Finding the Building

Before anything can happen, the user has to find your application.

Domain Name

A domain name is the human-readable address of a website.

Examples:

example.com
google.com
github.com
myapp.company.com

In our office analogy:

Domain name = Street address

Humans are bad at remembering raw IP addresses.

So instead of typing:

142.250.190.78

we type:

google.com

The domain name is not the server itself.

It is the name that points to where the server can be found.

DNS

DNS stands for Domain Name System.

DNS translates a domain name into an IP address.

In the office analogy:

DNS = Address lookup service

You ask:

Where is example.com?

DNS responds:

The server is at this IP address.

A simplified flow:

Browser
  |
  v
DNS Lookup
  |
  v
IP Address
  |
  v
Server

Without DNS, users would need to remember numeric addresses for every website.

That would be terrible.

IP Address

An IP address identifies a machine or network location.

In the office analogy:

IP address = Actual physical location

A domain is what humans use.

An IP address is what machines use.

Example:

example.com -> 93.184.216.34

The domain is the friendly label.

The IP is where traffic actually goes.

URL

A URL is the full address of a resource.

Example:

https://example.com/users/123?tab=settings

It contains several parts:

Part	Meaning
`https`	Protocol
`example.com`	Domain
`/users/123`	Path
`?tab=settings`	Query string

In the office analogy:

URL = Full instruction for reaching a specific office, desk, or document

The domain gets you to the building.

The path tells you what you want inside the building.

Part 2: Browser, Requests, and Responses

Once the address is found, the browser sends a request.

Browser

The browser is the user’s tool for interacting with the web.

Examples:

Chrome
Safari
Firefox
Edge

In the office analogy:

Browser = Visitor's assistant

The browser:

Finds websites
Sends requests
Receives responses
Renders pages
Stores cookies
Runs JavaScript
Enforces browser security rules

The browser is not just a display window.

It is an active participant in web security and communication.

HTTP Request

When your browser visits a website, it sends an HTTP request.

Example:

GET /dashboard HTTP/1.1
Host: example.com

In the office analogy:

HTTP request = Visitor asking the office for something

The request says:

I want this resource.

A request may include:

URL path
Method
Headers
Cookies
Request body
Authentication token

HTTP Response

The server replies with an HTTP response.

Example:

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

The response may contain:

HTML
CSS
JavaScript
JSON
Images
Error messages
Redirect instructions

In the office analogy:

HTTP response = Office giving something back to the visitor

The web is mostly request and response.

Browser -> Request -> Server
Browser <- Response <- Server

HTTP Methods

HTTP methods describe the kind of action being requested.

Method	Common Meaning	Office Analogy
GET	Read data	Ask to view a document
POST	Create data	Submit a new form
PUT	Replace data	Replace an entire record
PATCH	Update part of data	Correct one field
DELETE	Delete data	Remove a record

Examples:

GET /users/123
POST /users
PATCH /users/123
DELETE /users/123

The method tells the server what kind of operation is intended.

HTTP Status Codes

Status codes summarize what happened.

Status Code	Meaning
200	OK
201	Created
301	Moved permanently
302	Temporary redirect
400	Bad request
401	Not authenticated
403	Not authorized
404	Not found
409	Conflict
429	Too many requests
500	Server error
502	Bad gateway
503	Service unavailable

Office analogy:

Status	Office Meaning
200	Request completed
401	Security does not know who you are
403	Security knows you, but you lack access
404	The requested document does not exist
500	Something broke inside the office
503	Office is temporarily unavailable

The difference between 401 and 403 is important.

401 = Who are you?
403 = You are known, but not allowed.

Part 3: Frontend, Backend, and Database

Now we enter the building.

Frontend

The frontend is what users see and interact with.

Examples:

Pages
Buttons
Forms
Menus
Search bars
Dashboards
Charts

In the office analogy:

Frontend = Reception desk

Reception does not perform every task.

Reception:

Greets visitors
Shows information
Collects input
Sends requests to departments
Displays results

Frontend technologies include:

HTML
CSS
JavaScript
TypeScript
React
Vue
Angular
Svelte
Next.js
Nuxt
Astro

The frontend should be pleasant, clear, and responsive.

But it should not be trusted blindly.

Why?

Because frontend code runs on the user’s machine.

Users can inspect it, modify it, or bypass it.

Important rule:

Never rely only on frontend checks for security.

Frontend validation is useful for user experience.

Backend validation is required for security.

HTML

HTML defines the structure of a web page.

In the office analogy:

HTML = The layout of the reception area

It says:

This is a heading.
This is a paragraph.
This is a form.
This is a button.
This is a link.

Example:

<h1>Account Settings</h1>
<button>Save</button>

HTML gives the page meaning and structure.

CSS

CSS controls appearance.

In the office analogy:

CSS = Interior design

It controls:

Color
Font
Spacing
Layout
Animation
Responsiveness

Example:

button {
  background: black;
  color: white;
}

HTML says what something is.

CSS says how it looks.

JavaScript

JavaScript adds behavior.

In the office analogy:

JavaScript = Reception desk procedures

It controls:

Button clicks
Form submissions
Dynamic updates
API calls
Client-side routing
Interactive charts

Example:

button.addEventListener("click", saveSettings)

HTML is structure.

CSS is style.

JavaScript is behavior.

Backend

The backend is where most application work happens.

In the office analogy:

Backend = Employees and departments behind reception

The backend handles:

Business logic
Authentication
Authorization
Database queries
Payments
File processing
Email sending
Logging
Validation
Integrations with other services

Backend technologies include:

Python
Node.js
Go
Java
C#
Ruby
PHP
Rust

Backend frameworks include:

Django
FastAPI
Flask
Express
NestJS
Spring Boot
Rails
Laravel
ASP.NET

The backend is the part users do not directly see.

But it is where the important rules live.

Database

The database stores persistent information.

In the office analogy:

Database = Filing room / records archive

A database may store:

User accounts
Orders
Messages
Product data
Billing records
Audit logs
Permissions
Application settings

Common databases:

Database	Type
PostgreSQL	Relational
MySQL	Relational
SQLite	Relational
MongoDB	Document
Redis	Key-value / cache
Elasticsearch	Search
DynamoDB	Key-value / document
Cassandra	Wide-column

The database is usually one of the most important parts of the system.

If the application crashes, it can restart.

If the database is corrupted or lost, the business may be in serious trouble.

Relational Database

A relational database stores data in tables.

Example:

users
-----
id
name
email

orders
------
id
user_id
amount
created_at

In the office analogy:

Relational database = Organized filing cabinets with strict forms

Relational databases are good when data has clear structure and relationships.

Example:

One user can have many orders.
One order belongs to one user.

PostgreSQL and MySQL are common relational databases.

NoSQL Database

NoSQL is a broad category.

It often means the database does not use traditional relational tables as its main model.

Examples:

Document database
Key-value database
Wide-column database
Graph database

In the office analogy:

NoSQL database = Flexible storage rooms for different document shapes

NoSQL can be useful when:

Data structure changes often
Scale requirements are unusual
Low-latency key lookup matters
Documents are naturally nested

But NoSQL is not automatically better.

It is just a different trade-off.

Database Index

A database index makes lookups faster.

Office analogy:

Index = Catalog card

Without an index, an employee may search every file.

With an index, they jump directly to the right file.

Example:

CREATE INDEX idx_users_email ON users(email);

Indexes improve reads.

But they add cost to writes.

Why?

Because every time data changes, the index must also be updated.

Trade-off:

Faster lookup
Slower writes
More storage

Part 4: APIs

The frontend and backend need a way to communicate.

That is where APIs come in.

API

API stands for Application Programming Interface.

An API is a defined way for one system to talk to another.

In the office analogy:

API = Internal request form

Reception cannot yell random instructions into the building.

It must submit requests in a format departments understand.

Example API request:

GET /users/123

Meaning:

Please give me user 123.

Example response:

{
  "id": 123,
  "name": "Alice",
  "role": "admin"
}

An API defines:

What can be requested
What data must be provided
What response will come back
What errors may happen

Good APIs are predictable.

Bad APIs feel like guessing.

REST API

REST is a common API style built around resources.

A resource is a thing.

Examples:

User
Order
Product
Invoice
Message

REST uses URLs and HTTP methods.

Examples:

GET /users
GET /users/123
POST /users
PATCH /users/123
DELETE /users/123

Office analogy:

REST = Standard forms for standard records

REST is popular because it is:

Simple
Familiar
Cache-friendly
Easy to debug
Easy to expose publicly

A typical REST response uses JSON.

JSON

JSON stands for JavaScript Object Notation.

It is a common format for sending data.

Example:

{
  "id": 123,
  "name": "Alice",
  "active": true
}

Office analogy:

JSON = Standard paper form

JSON is popular because it is:

Human-readable
Easy for machines to parse
Supported almost everywhere

GraphQL

GraphQL is another API style.

Instead of requesting a fixed endpoint, the client asks for exactly the fields it wants.

Example:

{
  user(id: 123) {
    name
    email
    department
  }
}

Office analogy:

GraphQL = Custom report request

Instead of asking for a full pre-made report, you say:

Give me only these fields.

Advantages:

Flexible data fetching
Reduces over-fetching
Useful for complex frontends

Disadvantages:

More complex server implementation
Harder caching
Authorization can be trickier
Query cost must be controlled

GraphQL is powerful, but it is not automatically simpler than REST.

RPC

RPC stands for Remote Procedure Call.

Instead of thinking in resources, RPC thinks in actions.

Example:

POST /sendInvoice
POST /calculateTax
POST /startWorkflow

Office analogy:

RPC = Ask a department to perform a specific task

REST often says:

Operate on this resource.

RPC often says:

Run this action.

Both can be valid.

API Versioning

APIs change over time.

But old clients may still depend on old behavior.

Versioning helps manage change.

Examples:

/api/v1/users
/api/v2/users

Office analogy:

API version = Updated form template

If the office changes a form, old departments may still need the old form for a while.

Versioning prevents breaking everyone at once.

Part 5: Identity and Access

Now we reach one of the most confusing parts of web development.

How does a website know who you are?

Authentication

Authentication answers:

Who are you?

In the office analogy:

Authentication = Security guard checking ID

Examples:

Password login
One-time code
Passkey
Google login
GitHub login
Microsoft login
Hardware security key

When authentication succeeds, the system knows the user’s identity.

Authentication does not automatically mean the user can do everything.

It only proves identity.

Authorization

Authorization answers:

What are you allowed to do?

In the office analogy:

Authorization = Badge permissions

Example:

Alice logs in successfully.

Now the system checks:

Resource	Alice’s Access
Dashboard	Allowed
Billing page	Allowed
Admin panel	Denied
Payroll records	Denied

Authentication says:

This is Alice.

Authorization says:

Alice may access billing, but not payroll.

A lot of bugs happen when developers confuse authentication and authorization.

User Role

A role is a broad permission category.

Examples:

Admin
Editor
Viewer
Billing manager
Support agent

Office analogy:

Role = Job title on badge

Roles are simple and common.

But they can become too coarse.

Example:

Admin

may become too powerful if used carelessly.

Permission

A permission is a specific allowed action.

Examples:

read:users
write:users
delete:orders
view:billing
export:data

Office analogy:

Permission = Specific room access on badge

Roles group permissions.

Example:

Role: Billing Manager
Permissions:
- view invoices
- create invoices
- refund payments

Good authorization design usually combines roles and permissions.

Session

A session is a server-side record of a logged-in user.

Office analogy:

Session = Visitor record at security desk

Security stores:

Session ID: 8472
User: Alice
Expires: 5 PM

The browser stores only the session ID.

Example:

session_id=8472

When the browser sends a request, the server looks up the session ID.

If the session exists and is valid, the user is considered logged in.

Advantages:

Easy to revoke
Easy logout
Centralized control
Server can update session state

Disadvantages:

Server must store sessions
Scaling requires shared session storage
More backend coordination

Sessions are stateful.

The server remembers users.

A cookie is a small piece of data stored by the browser.

Office analogy:

Cookie = Small note kept by the visitor's assistant

A cookie may store:

Session ID
Refresh token
Preferences
Tracking identifier
Shopping cart ID

A cookie is not authentication by itself.

It is just storage and transport.

What matters is what the cookie contains.

Example:

Set-Cookie: session_id=8472; HttpOnly; Secure; SameSite=Lax

Important cookie flags:

Flag	Meaning
`HttpOnly`	JavaScript cannot read it
`Secure`	Sent only over HTTPS
`SameSite`	Controls cross-site sending
`Max-Age` / `Expires`	Controls lifetime
`Path`	Limits where cookie is sent
`Domain`	Controls which domain receives it

A safer authentication cookie usually uses:

HttpOnly
Secure
SameSite=Lax or Strict

Access Token

An access token proves that a request is allowed.

Office analogy:

Access token = Temporary access badge

Every time the user calls the API, the access token is sent.

Example:

Authorization: Bearer eyJhbGciOi...

Access tokens are usually short-lived.

Why?

Because if they are stolen, the damage window is smaller.

Typical lifetime:

minutes
minutes
minutes
hour

It depends on the application.

Refresh Token

A refresh token is used to obtain a new access token.

Office analogy:

Refresh token = Secure locker key used to get a new temporary badge

The access token expires often.

The refresh token lasts longer.

A common flow:

Access token expires
  |
  v
Browser uses refresh token
  |
  v
Server issues new access token

Refresh tokens should be protected carefully.

They are often stored in HttpOnly cookies.

JWT

JWT stands for JSON Web Token.

A JWT is a signed token format.

Office analogy:

JWT = Signed visitor badge

A JWT may contain claims like:

{
  "sub": "user_123",
  "role": "admin",
  "exp": 1735689600
}

Important:

JWT is a format.

It is not storage.

It is not automatically secure.

It is not the same thing as OAuth.

A JWT is useful because the server can verify the signature.

If the signature is valid, the server can trust that the token has not been modified.

Advantages:

Self-contained
Fast verification
Useful across distributed systems
No database lookup required for every request

Disadvantages:

Harder to revoke immediately
Can become too large
Sensitive claims should not be placed inside carelessly
Must expire quickly if used as an access token

A common mistake:

“We use JWT, so we are stateless and secure.”

Not necessarily.

JWT solves one problem: signed claims.

It does not solve all authentication problems.

Opaque Token

An opaque token is a token whose contents are not meaningful to the client.

Example:

a8f9d2c7e1b4...

Office analogy:

Opaque token = Random badge number

The server must look it up.

Advantages:

Easy to revoke
No sensitive claims exposed
Server controls meaning

Disadvantages:

Requires lookup
Less self-contained

Opaque tokens are common in systems that want centralized control.

Stateful vs Stateless Authentication

Stateful authentication means the server remembers the user.

Example:

Session ID -> Server lookup -> User

Stateless authentication means the token carries enough information to verify the user.

Example:

JWT -> Verify signature -> Read claims

Office analogy:

Stateful:

Security desk keeps visitor records.

Stateless:

Visitor badge contains signed information.

Trade-off:

Stateful	Stateless
Easy revocation	Easier horizontal scaling
Server stores session	Server verifies token
Central control	Less central lookup
Good for traditional web apps	Good for APIs and distributed systems

Neither is always better.

The right answer depends on the system.

OAuth

OAuth is delegated authorization.

In simple terms:

OAuth lets one system grant another system limited access.

Office analogy:

OAuth = Trusted external office issues proof that another office accepts

Example:

You click:

Sign in with Google

Your app does not directly handle your Google password.

Instead:

You go to Google.
Google verifies you.
Google sends proof back to the app.
The app trusts that proof.

OAuth is often used for login, but OAuth itself is mainly about delegated access.

OpenID Connect

OpenID Connect, or OIDC, adds identity on top of OAuth.

Simple version:

OAuth = Access delegation
OIDC = Login identity layer

If a website says:

Sign in with Google

it is often using OIDC.

Office analogy:

OAuth = You may access this department.
OIDC = This is who the visitor is.

SSO

SSO stands for Single Sign-On.

It allows one login to access multiple applications.

Office analogy:

SSO = One company badge works across many office buildings

Examples:

Google Workspace login
Microsoft Entra ID login
Okta login
Auth0 login

SSO is common in companies because employees should not manage separate passwords for every tool.

MFA

MFA stands for Multi-Factor Authentication.

It requires more than one proof of identity.

Examples:

Password + phone code
Password + hardware key
Password + authenticator app
Passkey + device verification

Office analogy:

MFA = ID card plus fingerprint check

MFA reduces risk when passwords are stolen.

Part 6: Browser Storage

The browser can store data in several ways.

These are often confused.

Storage	Lifetime	Sent Automatically?	JavaScript Access?
Cookie	Configurable	Yes, if domain/path match	Depends on HttpOnly
localStorage	Until cleared	No	Yes
sessionStorage	Browser tab session	No	Yes

Office analogy:

Storage	Analogy
Cookie	Note automatically shown at the right office
localStorage	Notebook kept by assistant
sessionStorage	Temporary notepad for one visit

Important security point:

If malicious JavaScript runs on your page, it can read localStorage.

It cannot read an HttpOnly cookie.

That is why storing long-lived tokens in localStorage is often discouraged.

Why localStorage Can Be Risky for Tokens

A common beginner pattern:

localStorage.setItem("token", token)

This is convenient.

But if the page has an XSS vulnerability, malicious JavaScript may read the token.

Office analogy:

You taped your access badge to the receptionist's desk.
Anyone who can enter the desk area can copy it.

A safer common pattern:

Access token: memory
Refresh token: HttpOnly Secure cookie

This does not make the app magically secure.

But it reduces exposure.

Part 7: Web Security Concepts

Security is not one feature.

It is a set of layers.

HTTPS

HTTPS encrypts communication between browser and server.

Office analogy:

HTTPS = Sealed envelope

Without HTTPS, attackers may see or modify traffic.

Risks without HTTPS:

Password theft
Token theft
Session hijacking
Data leakage
Content tampering

Modern rule:

No HTTPS = no real web security.

TLS

TLS is the cryptographic protocol behind HTTPS.

Most people say HTTPS when talking about secure websites.

TLS is the underlying security mechanism.

Office analogy:

HTTPS = Using sealed envelopes
TLS = The sealing method

XSS

XSS stands for Cross-Site Scripting.

It happens when an attacker gets malicious JavaScript to run in another user’s browser.

Example:

<script>stealTokens()</script>

Office analogy:

An attacker inserts fake instructions into official office documents.
Employees follow the instructions because they appear inside trusted documents.

XSS can allow attackers to:

Steal data
Perform actions as the user
Read localStorage
Modify the page
Capture input

Defenses:

Escape user input
Sanitize HTML
Use Content Security Policy
Avoid dangerous HTML injection
Validate and encode output
Use secure frontend frameworks correctly

CSRF

CSRF stands for Cross-Site Request Forgery.

It tricks a user’s browser into sending an unwanted request to a site where the user is already logged in.

Office analogy:

Someone slips a form into your outgoing mail pile.
The form has your valid identity attached, but you did not intend the action.

CSRF is especially relevant when browsers automatically send cookies.

Example:

You are logged into bank.com.
An attacker tricks your browser into submitting a transfer request.
Your browser includes your bank cookies automatically.

Defenses:

SameSite cookies
CSRF tokens
Double-submit cookies
Requiring re-authentication for sensitive actions
Checking origin headers

Important distinction:

CSRF abuses automatic credentials.
XSS runs malicious code inside the trusted page.

CORS

CORS stands for Cross-Origin Resource Sharing.

It controls which browser-based web pages are allowed to read responses from another origin.

Office analogy:

CORS = Policy saying which outside reception desks may talk to this office through browsers

Important:

CORS is enforced by browsers.

CORS does not stop:

curl
Postman
Server-to-server requests
Attackers directly calling your API

CORS is not a replacement for authentication.

Bad assumption:

We configured CORS, so our API is secure.

Better understanding:

CORS controls browser access.
Authentication and authorization control real access.

Same-Origin Policy

The same-origin policy is a browser security rule.

It prevents one website from freely reading data from another website.

An origin includes:

Scheme + Host + Port

Example:

https://example.com

Different origins:

http://example.com
https://example.com
https://api.example.com
https://example.com:8443

Office analogy:

Different branches cannot freely read each other's internal documents.

CORS is a controlled exception to the same-origin policy.

Content Security Policy

Content Security Policy, or CSP, helps reduce XSS risk.

It tells the browser what scripts, styles, images, and other resources are allowed.

Office analogy:

CSP = Rulebook saying which instruction sources employees may trust

Example:

Content-Security-Policy: default-src 'self'

CSP is not a replacement for secure coding.

But it is a strong additional layer.

Rate Limiting

Rate limiting restricts how many requests a client can make.

Office analogy:

A visitor may submit only 100 forms per minute.

Rate limiting helps prevent:

Brute force attacks
API abuse
Scraping
Accidental overload
Denial-of-service amplification

Example response:

429 Too Many Requests

Input Validation

Input validation checks whether data is acceptable.

Office analogy:

Reception checks whether a form is complete and valid before sending it to a department.

Examples:

Email must look like an email.
Age must be a number.
File size must be below a limit.
Date must be valid.
Role must be one of the allowed roles.

Frontend validation improves user experience.

Backend validation protects the system.

You need both.

SQL Injection

SQL injection happens when user input is treated as database code.

Unsafe example:

SELECT * FROM users WHERE email = '$email';

If $email contains malicious SQL, the query may behave dangerously.

Office analogy:

A visitor writes instructions on a form, and the filing room blindly follows them as official commands.

Defenses:

Parameterized queries
ORM query parameters
Input validation
Least-privilege database users
Avoid string-building SQL with untrusted input

Principle of Least Privilege

A user or service should have only the access it needs.

Office analogy:

Do not give every employee a master key.

Examples:

Frontend cannot access database directly.
Read-only service should not have write access.
Billing worker should not access admin settings.
Database user should not have unnecessary admin privileges.

Least privilege limits damage when something goes wrong.

Part 8: Performance and Scaling

A small web app can run on one server.

A popular web app usually cannot.

Cache

A cache stores frequently used data closer to where it is needed.

Office analogy:

Instead of walking to the filing room every time, employees keep frequently used documents on their desk.

Examples:

Browser cache
CDN cache
Application cache
Database query cache
Redis cache

Caching improves performance because it avoids repeated expensive work.

Common cached data:

Images
CSS
JavaScript
API responses
User sessions
Database query results

Trade-off:

Caching introduces a hard problem:

How do we know the cached copy is still correct?

This is called cache invalidation.

Browser Cache

The browser can store files locally.

Examples:

Images
CSS
JavaScript
Fonts

Office analogy:

The visitor keeps a copy of common brochures instead of asking reception every time.

Browser caching makes repeat visits faster.

CDN

CDN stands for Content Delivery Network.

A CDN stores content in many geographic locations.

Office analogy:

Instead of making everyone visit headquarters, the company places document kiosks in many cities.

CDNs are useful for:

Images
Videos
CSS
JavaScript
Downloads
Static pages

Benefits:

Lower latency
Reduced server load
Better global performance
DDoS protection in some cases

Examples:

Cloudflare
Fastly
Akamai
Amazon CloudFront

Load Balancer

A load balancer distributes traffic across multiple servers.

Office analogy:

A traffic director sends visitors to different buildings so no single building becomes overloaded.

Example:

Request 1 -> Server A
Request 2 -> Server B
Request 3 -> Server C

Load balancers improve:

Scalability
Availability
Fault tolerance

If one server fails, the load balancer can stop sending traffic to it.

Reverse Proxy

A reverse proxy sits in front of application servers and routes requests.

Office analogy:

A front gate receives all visitors and sends them to the correct department.

Reverse proxies can handle:

Routing
TLS termination
Compression
Caching
Rate limiting
Security headers
Static file serving

Examples:

Nginx
HAProxy
Traefik
Envoy
Cloudflare

A simple flow:

Browser
  |
  v
Reverse Proxy
  |
  v
Application Server

Horizontal Scaling

Horizontal scaling means adding more machines.

Office analogy:

Open more office buildings.

Example:

1 server -> 3 servers -> 10 servers

This is common for web applications.

It usually requires:

Load balancing
Shared database
Shared cache
Stateless application servers
Centralized logging

Vertical Scaling

Vertical scaling means making one machine bigger.

Office analogy:

Make the existing building larger.

Example:

2 CPUs -> 8 CPUs
8 GB RAM -> 64 GB RAM

Vertical scaling is simpler.

But it has limits.

At some point, one machine cannot keep growing.

Availability

Availability means the system is usable when people need it.

Office analogy:

The office is open and functioning.

High availability usually requires:

Multiple servers
Redundant databases
Health checks
Failover
Monitoring
Backups
Incident response

A system can be fast but not highly available.

A system can also be highly available but slow.

They are related but not identical.

Latency

Latency is the time it takes to get a response.

Office analogy:

How long a visitor waits before getting an answer.

High latency feels slow.

Common causes:

Long database queries
Network distance
Large files
Slow backend logic
Too many API calls
Cold starts
Overloaded servers

Reducing latency often requires measuring where time is spent.

Guessing is unreliable.

Throughput

Throughput is how much work the system can handle over time.

Office analogy:

How many visitors the office can serve per hour.

Latency is about one request.

Throughput is about many requests.

A system needs both:

Fast enough for one user.
Strong enough for many users.

Part 9: Real-Time and Asynchronous Communication

Not every task should happen immediately inside a request.

Polling

Polling means repeatedly asking for updates.

Example:

Is the report ready?
Is the report ready?
Is the report ready?

Office analogy:

A visitor keeps returning to reception every few seconds.

Advantages:

Simple
Works almost everywhere
Easy to reason about

Disadvantages:

Inefficient
Adds unnecessary load
Updates are not truly instant

Polling is fine for small systems or low-frequency updates.

Long Polling

Long polling is a smarter version of polling.

The client asks for updates.

The server waits until something happens or a timeout occurs.

Office analogy:

The visitor asks reception to hold the request open until the report is ready.

Long polling reduces constant repeated requests.

But it is still less elegant than true streaming when frequent updates are needed.

Server-Sent Events

Server-Sent Events, or SSE, allow the server to send one-way updates to the browser.

Office analogy:

The office announcement speaker broadcasts updates to visitors.

Good for:

Notifications
Job progress
Status updates
Monitoring dashboards
News feeds

SSE is simpler than WebSockets when communication only needs to go from server to client.

WebSockets

WebSockets create a persistent two-way connection.

Office analogy:

A permanent phone line between visitor and office.

Useful for:

Chat
Multiplayer games
Collaborative editing
Live dashboards
Trading apps
Real-time notifications

Flow:

Client <-------> Server

Trade-offs:

More complex infrastructure
More complex scaling
Harder debugging
Long-lived connections must be managed carefully

Use WebSockets when two-way real-time communication is truly needed.

Do not use them just because they sound advanced.

Queue

A queue stores work to be processed later.

Office analogy:

A stack of work forms waiting in an inbox.

Instead of doing everything during the user’s request, the backend can add a job to a queue.

Example:

User uploads video
  |
  v
Backend stores file
  |
  v
Backend adds "process video" job to queue
  |
  v
Worker processes job later

Queues are useful for:

Email sending
Video processing
Report generation
Data imports
Background cleanup
Notifications
Long-running jobs

Common queue systems:

RabbitMQ
Redis queues
Amazon SQS
Kafka
Google Pub/Sub
Celery
Sidekiq

Worker

A worker processes background jobs.

Office analogy:

Back-office employee who handles tasks from the inbox.

Workers allow the main application to respond quickly.

Example:

Without queue:

User waits 60 seconds for report.

With queue:

User submits request.
System says: Report is being generated.
Worker creates report in background.
User gets notified later.

This improves user experience and reliability.

Message Broker

A message broker moves messages between systems.

Office analogy:

Internal mailroom that routes envelopes between departments.

Examples:

RabbitMQ
Kafka
NATS
Redis Streams
Google Pub/Sub
Amazon SNS/SQS

Message brokers help decouple systems.

Instead of Service A directly calling Service B, Service A publishes an event.

Service B consumes it when ready.

Event-Driven Architecture

In event-driven systems, services react to events.

Example:

UserSignedUp
PaymentCompleted
OrderShipped
PasswordChanged

Office analogy:

Departments listen for company announcements and act when relevant.

Example:

UserSignedUp event
  |
  +--> Send welcome email
  +--> Create billing profile
  +--> Initialize user settings
  +--> Notify analytics

This can make systems flexible.

But it can also make debugging harder.

Part 10: Deployment and Environments

Code on a laptop is not the same as code running in production.

Environment

An environment is a place where the application runs.

Common environments:

Environment	Purpose
Local	Developer machine
Development	Shared test area
Staging	Production-like testing
Production	Real users

Office analogy:

Environment = Different branch office

Local:

Your personal desk.

Development:

Practice office.

Staging:

Dress rehearsal office.

Production:

Real office with real customers.

Production deserves special care.

Environment Variables

Environment variables are configuration values provided outside the code.

Examples:

DATABASE_URL
API_KEY
SECRET_KEY
NODE_ENV
DEBUG

Office analogy:

Environment variables = Branch-specific instruction sheet

The same code may run in staging and production, but with different configuration.

Example:

Staging database URL != Production database URL

Never hardcode secrets directly into source code.

Build

A build prepares code for running or deployment.

Frontend build may:

Bundle JavaScript
Minify files
Compile TypeScript
Optimize images
Generate static pages

Backend build may:

Compile code
Package dependencies
Build a container image

Office analogy:

Build = Preparing all documents, tools, and furniture before opening the office.

Deploy

Deployment means releasing the application to an environment.

Office analogy:

Deploy = Open the new office version for use.

Deployment may involve:

Uploading files
Restarting services
Running database migrations
Updating containers
Changing traffic routing
Invalidating caches

A deployment is successful only if the application works after release.

CI/CD

CI/CD stands for Continuous Integration and Continuous Delivery or Deployment.

CI checks code automatically.

CD releases code automatically or semi-automatically.

Office analogy:

CI = Inspect every office change before approval.
CD = Roll out approved changes to branch offices.

CI may run:

Tests
Linters
Type checks
Security scans
Build checks

CD may:

Deploy to staging
Deploy to production
Run migrations
Roll back on failure

CI/CD reduces manual mistakes.

Container

A container packages an application with its dependencies.

Office analogy:

Container = Portable office room with everything needed inside.

A container includes:

Application code
Runtime
System libraries
Configuration defaults

Docker is the most common container tool.

Containers help solve:

It works on my machine.

Because the application runs in a consistent environment.

Image

A container image is the blueprint for creating containers.

Office analogy:

Image = Blueprint for portable office room
Container = Running room built from that blueprint

Example:

docker build -t myapp .
docker run myapp

The image is static.

The container is running.

Kubernetes

Kubernetes manages containers across many machines.

Office analogy:

Kubernetes = Facilities manager for many portable office rooms.

It handles:

Starting containers
Restarting failed containers
Scaling replicas
Networking
Service discovery
Rolling updates
Configuration
Secrets
Health checks

Kubernetes is powerful.

It is also complex.

You usually do not need it for small applications.

Serverless

Serverless means you deploy functions or services without managing servers directly.

Examples:

AWS Lambda
Google Cloud Functions
Azure Functions
Cloudflare Workers
Vercel functions

Office analogy:

Serverless = On-demand contractor who appears when a task arrives.

Benefits:

Less server management
Scales automatically
Pay per use

Trade-offs:

Cold starts
Execution time limits
Vendor-specific behavior
Harder debugging in some cases

Serverless does not mean there are no servers.

It means you do not manage them directly.

Part 11: Monitoring, Logging, and Reliability

A real production system needs visibility.

Logging

Logs are records of what happened.

Office analogy:

Logs = Office activity journal

Examples:

User logged in
Payment failed
Database query timed out
API returned 500
Email sent

Good logs help answer:

What happened?
When did it happen?
Who was affected?
Which request failed?
Which service caused the problem?

Bad logs either say too little or leak too much.

Avoid logging sensitive data such as:

Passwords
Tokens
Full credit card numbers
Private health data
Secrets
Sensitive personal information

Metrics

Metrics are numeric measurements over time.

Office analogy:

Metrics = Office dashboard

Examples:

Requests per second
Error rate
Latency
CPU usage
Memory usage
Queue length
Database connections
Cache hit rate

Metrics show system health.

Logs explain individual events.

You usually need both.

Tracing

Tracing follows a request across multiple services.

Office analogy:

A tracking slip follows a visitor request through every department.

Example:

Frontend
  |
  v
API Gateway
  |
  v
User Service
  |
  v
Billing Service
  |
  v
Database

Tracing helps answer:

Where did this request become slow?

This matters in microservice systems.

Alerting

Alerting notifies people when something is wrong.

Office analogy:

Fire alarm or operations phone call.

Examples:

Error rate above 5%
API latency above 2 seconds
Database unavailable
Disk almost full
Payment failures increasing
Queue length growing too fast

Good alerts are actionable.

Bad alerts create noise.

If every small issue pages someone, people stop trusting alerts.

Health Check

A health check tells whether a service is working.

Office analogy:

A front gate asks each department: Are you open and ready?

Example:

GET /health

Response:

{
  "status": "ok"
}

Load balancers and orchestration systems use health checks to route traffic safely.

Backup

A backup is a copy of important data.

Office analogy:

Duplicate archive stored safely elsewhere.

Backups protect against:

Accidental deletion
Database corruption
Ransomware
Failed migrations
Hardware failure
Human error

A backup that has never been tested is only a hope.

You need restore tests.

Disaster Recovery

Disaster recovery is the plan for major failure.

Office analogy:

If headquarters burns down, how does the company continue operating?

Disaster recovery considers:

Backups
Restore time
Alternate regions
Failover
Data loss tolerance
Communication plans

Two important terms:

Term	Meaning
RTO	Recovery Time Objective: how long until service returns
RPO	Recovery Point Objective: how much data loss is acceptable

Part 12: Common Architecture Patterns

Now that the pieces are clear, we can describe common system shapes.

Static Website

A static website serves pre-built files.

Examples:

HTML
CSS
JavaScript
Images

Office analogy:

A brochure stand.

No employee has to generate a custom answer for every visitor.

Good for:

Blogs
Documentation
Marketing pages
Portfolios

Tools:

Jekyll
Hugo
Astro
Eleventy
Next.js static export
GitHub Pages

Benefits:

Fast
Cheap
Secure
Easy to host

Limitations:

Limited dynamic behavior unless using APIs
No server-side user-specific logic by default

Server-Rendered App

A server-rendered app generates HTML on the server.

Office analogy:

Reception asks employees to prepare a custom document before handing it to the visitor.

Examples:

Rails
Django templates
Laravel Blade
Next.js server rendering
Nuxt server rendering

Benefits:

Good initial load
Good SEO
Centralized logic

Trade-offs:

Server does more work
Scaling may require more backend capacity

Single Page Application

A Single Page Application, or SPA, loads JavaScript once and updates the page dynamically.

Office analogy:

Reception gives the visitor an interactive kiosk that talks to departments directly through APIs.

Examples:

React SPA
Vue SPA
Angular app

Benefits:

Smooth interactions
App-like feel
Clear frontend/backend separation

Trade-offs:

More JavaScript
SEO complexity
Frontend state complexity
Authentication handling complexity

Full-Stack Framework

A full-stack framework combines frontend and backend patterns.

Examples:

Next.js
Nuxt
Remix
SvelteKit
Rails
Django
Laravel

Office analogy:

A company with a standard blueprint for reception, departments, forms, and records.

Benefits:

Faster development
Conventions
Integrated routing
Data loading patterns
Deployment patterns

Trade-off:

Framework rules
Less flexibility in some areas
Migration cost if the framework changes direction

Monolith

A monolith is one application containing many features.

Office analogy:

One large building with all departments inside.

Benefits:

Easier development at first
Simple deployment
Easier debugging
Strong consistency
Fewer network calls

Trade-offs:

Can become large
Teams may step on each other
Scaling parts independently is harder

A monolith is not bad.

A well-structured monolith is often better than premature microservices.

Microservices

Microservices split a system into smaller independent services.

Office analogy:

Many specialized buildings connected by internal mail and phone lines.

Example services:

User service
Billing service
Search service
Notification service
Reporting service

Benefits:

Independent scaling
Independent deployment
Team ownership
Technology flexibility

Trade-offs:

Network complexity
Harder debugging
Distributed failures
Data consistency problems
More operational overhead

Microservices solve organizational and scaling problems.

They also create new problems.

API Gateway

An API gateway sits in front of APIs and routes requests.

Office analogy:

Central reception for many departments and buildings.

It may handle:

Routing
Authentication
Rate limiting
Request transformation
Logging
API versioning

API gateways are common in microservice architectures.

Part 13: Data Flow Examples

Let’s make the system concrete.

Example 1: User Opens Dashboard

User opens /dashboard
  |
  v
Browser sends request
  |
  v
Server checks session or token
  |
  v
Backend verifies user
  |
  v
Backend loads dashboard data
  |
  v
Database returns records
  |
  v
Server responds
  |
  v
Browser renders dashboard

Office version:

Visitor asks reception for dashboard.
Security checks badge.
Employee fetches records.
Reception presents result.

Example 2: User Logs In

User submits email and password
  |
  v
Backend validates credentials
  |
  v
Backend creates session or token
  |
  v
Browser stores cookie or token
  |
  v
Future requests include proof of login

Office version:

Visitor shows ID.
Security verifies it.
Security issues visitor record or badge.
Visitor uses it for future access.

Example 3: User Places an Order

Frontend sends POST /orders
  |
  v
Backend validates input
  |
  v
Backend checks authorization
  |
  v
Backend writes order to database
  |
  v
Backend sends confirmation

Office version:

Reception receives order form.
Department checks form.
Records office stores it.
Reception returns confirmation.

Example 4: User Uploads a File

User uploads file
  |
  v
Backend checks size and type
  |
  v
File stored in object storage
  |
  v
Database stores file metadata
  |
  v
Background worker scans or processes file

Office version:

Visitor submits a package.
Reception checks it.
Archive stores it.
Back-office worker processes it later.

Example 5: Long Report Generation

Bad design:

User requests report
  |
  v
Server spends 2 minutes generating it
  |
  v
User waits

Better design:

User requests report
  |
  v
Backend creates report job
  |
  v
Worker processes job
  |
  v
User receives notification

Office version:

Visitor requests a long report.
Reception gives a ticket.
Back office prepares report.
Visitor is notified when ready.

Part 14: Common Beginner Confusions

This section is the cheat sheet for concepts people often mix up.

Frontend vs Backend

Frontend:

What the user interacts with.

Backend:

Where the application rules and data processing happen.

Frontend can validate a form.

Backend must validate it again.

Frontend can hide a button.

Backend must still enforce permissions.

API vs Backend

The backend is the system doing the work.

The API is the interface used to request that work.

Office analogy:

Backend = Department
API = Request form

Server vs Database

The server runs application code.

The database stores data.

Office analogy:

Server = Office building or employees
Database = Filing room

They are often separate systems.

Cookie:

Small data stored by the browser.

Session:

Server-side record of a logged-in user.

A session ID is often stored inside a cookie.

That does not mean cookie and session are the same thing.

JWT:

Token format.

Cookie:

Browser storage and transport mechanism.

A JWT can be stored in a cookie.

A JWT can also be sent in an Authorization header.

They are different layers.

Authentication vs Authorization

Authentication:

Who are you?

Authorization:

What are you allowed to do?

A user can be authenticated but not authorized.

Example:

You are Alice.
Alice cannot access the admin page.

OAuth vs JWT

OAuth:

Authorization protocol / delegated access flow.

JWT:

Token format.

OAuth systems may use JWTs.

But OAuth and JWT are not the same thing.

CORS vs Authentication

CORS controls browser cross-origin behavior.

Authentication controls who can access the API.

CORS is not access control.

Bad:

Only our frontend can call the API because CORS blocks others.

Wrong.

Better:

CORS helps browsers enforce origin policy.
The API still needs authentication and authorization.

XSS vs CSRF

XSS:

Attacker runs malicious JavaScript inside your site.

CSRF:

Attacker tricks the browser into sending an unwanted request using existing credentials.

XSS is usually more dangerous because it can defeat many CSRF protections.

PUT vs PATCH

PUT usually replaces an entire resource.

PATCH updates part of a resource.

Example:

PUT /users/123

means:

Replace user 123 with this full representation.

Example:

PATCH /users/123

means:

Change only these fields.

Library vs Framework

Library:

Tool you call.

Framework:

Structure that calls your code.

Office analogy:

Library = Optional tool in a department.
Framework = Company operating manual.

React is often described as a library.

Next.js is a framework built around React.

Part 15: Practical Rules of Thumb

These are not universal laws.

But they are useful starting points.

Rule 1: Never Trust the Frontend

Anything in the browser can be inspected or modified.

Always enforce important rules on the backend.

Bad:

Hide admin button in frontend and assume user cannot access admin API.

Good:

Hide admin button for UX.
Also check admin permission on backend.

Rule 2: Validate Input Twice

Validate in the frontend for user experience.

Validate in the backend for security.

Frontend validation:

This field is required.

Backend validation:

This request is allowed and safe.

Rule 3: Use HTTPS Everywhere

Do not send passwords, tokens, cookies, or private data over plain HTTP.

Use HTTPS in production.

Always.

Rule 4: Keep Access Tokens Short-Lived

If an access token leaks, expiration limits damage.

Short-lived tokens are safer than long-lived ones.

Rule 5: Be Careful With localStorage

localStorage is convenient.

But it is readable by JavaScript.

If your page has XSS, localStorage tokens may be stolen.

Rule 6: Do Not Put Secrets in Frontend Code

Frontend code is public to users.

Never put these in frontend code:

Private API keys
Database passwords
Signing secrets
Admin tokens
Service credentials

If the browser can read it, users can read it.

Rule 7: Use the Database as the Source of Truth

Caches are copies.

Search indexes are copies.

Frontend state is a copy.

The database is usually the source of truth.

When copies disagree, know which one wins.

Rule 8: Add Caching Only When You Understand Staleness

Caching can make apps faster.

It can also make apps confusing.

Before caching, ask:

What data is cached?
How long is it valid?
Who can see it?
How is it invalidated?
What happens if it is stale?

Rule 9: Use Queues for Slow Work

If something takes a long time, consider a background job.

Examples:

Sending email
Generating reports
Processing videos
Importing large files
Running data analysis

Do not make users wait unnecessarily.

Rule 10: Logs Should Help, Not Leak

Good logs help debug.

Bad logs expose secrets.

Never log:

Passwords
Tokens
Secret keys
Sensitive personal data
Full payment details

Part 16: Extended Reference Table

Term	Plain Meaning	Office Analogy
User	Person using the app	Visitor
Browser	Software that accesses websites	Visitor’s assistant
Domain	Human-readable website name	Street address
DNS	Converts domain to IP	Address lookup
IP Address	Network location	Physical location
URL	Full web address	Full office instruction
HTTP	Request/response protocol	Office communication protocol
HTTPS	Encrypted HTTP	Sealed envelopes
Frontend	User interface	Reception desk
Backend	Application logic	Employees and departments
Server	Computer running software	Office building
Database	Persistent data storage	Filing room
API	Interface for communication	Request form
JSON	Data format	Standard paper form
REST	Resource-based API style	Standard office forms
GraphQL	Query-based API style	Custom report request
RPC	Action-based API style	Task request
Authentication	Prove identity	Security guard checks ID
Authorization	Check permissions	Badge access
Role	Permission group	Job title
Permission	Specific allowed action	Room access
Session	Server-side login record	Visitor record
Cookie	Browser-stored data	Note in pocket
Access Token	Short-lived credential	Temporary badge
Refresh Token	Token for renewal	Locker key
JWT	Signed token format	Signed badge
OAuth	Delegated access	Trusted external badge
OIDC	Identity layer on OAuth	Verified identity badge
SSO	One login for many apps	Company-wide badge
MFA	Multiple identity proofs	ID plus fingerprint
XSS	Malicious script injection	Fake instructions in trusted docs
CSRF	Forged request	Form slipped into outgoing mail
CORS	Browser origin policy	Approved caller policy
CSP	Script/source restrictions	Trusted instruction rulebook
Rate Limit	Request limit	Forms per minute limit
Cache	Faster copy of data	Documents on nearby desk
CDN	Global content cache	Regional document kiosk
Load Balancer	Traffic distributor	Visitor traffic director
Reverse Proxy	Front-facing router	Front gate
Queue	Stored background work	Work inbox
Worker	Background processor	Back-office employee
Message Broker	Routes messages	Internal mailroom
Container	Packaged runtime	Portable office room
Image	Container blueprint	Office room blueprint
Kubernetes	Container orchestrator	Facilities manager
Serverless	Managed execution	On-demand contractor
CI/CD	Automated test and release	Inspection and rollout pipeline
Logging	Event records	Office activity journal
Metrics	Numeric system measurements	Operations dashboard
Tracing	Request path tracking	Tracking slip
Alerting	Notifications on failure	Alarm system
Backup	Data copy	Duplicate archive
Disaster Recovery	Failure recovery plan	Emergency relocation plan

Part 17: Final Mental Model

A modern web application is not one thing.

It is a chain of cooperating parts.

User
  |
  v
Browser
  |
  v
Domain / DNS
  |
  v
Internet
  |
  v
CDN / Load Balancer / Reverse Proxy
  |
  v
Frontend
  |
  v
API
  |
  v
Backend
  |
  +-------------------+
  |                   |
  v                   v
Database             Cache
  |
  v
Background Jobs / Queues / Workers
  |
  v
External Services

The browser does not usually talk directly to the database.

The frontend does not own the security rules.

The API is not the same as the backend.

Cookies are not the same as sessions.

JWTs are not the same as OAuth.

CORS is not authentication.

A cache is not the source of truth.

A queue is not instant work.

A deployment is not successful just because the command finished.

These distinctions matter.

Once you understand the flow, the jargon becomes much less intimidating.

Final Thoughts

Web development feels complicated because people often teach it as a pile of disconnected terms.

But most concepts exist to answer practical questions:

How does the user reach us?
How do we show information?
How do we process requests?
How do we store data?
How do we know who the user is?
How do we decide what they can access?
How do we stay secure?
How do we stay fast?
How do we keep working when traffic grows?
How do we release changes safely?

The office-building model is not perfect, but it gives you a stable mental map.

Start with the journey:

Visitor -> Address -> Front Gate -> Reception -> Security -> Department -> Filing Room -> Response

Then map each technical term onto that journey.

That is the easiest way to understand full-stack web development without memorizing jargon.

The Big Picture

Core Mapping

Part 1: Finding the Building

Domain Name

DNS

IP Address

URL

Part 2: Browser, Requests, and Responses

Browser

HTTP Request

HTTP Response

HTTP Methods

HTTP Status Codes

Part 3: Frontend, Backend, and Database

Frontend

HTML

CSS

JavaScript

Backend

Database

Relational Database

NoSQL Database

Database Index

Part 4: APIs

API

REST API

JSON

GraphQL

RPC

API Versioning

Part 5: Identity and Access

Authentication

Authorization

User Role

Permission

Session

Cookie

Access Token

Refresh Token

JWT

Opaque Token

Stateful vs Stateless Authentication

OAuth

OpenID Connect

SSO

MFA

Part 6: Browser Storage

Cookie vs localStorage vs sessionStorage

Why localStorage Can Be Risky for Tokens

Part 7: Web Security Concepts

HTTPS

TLS

XSS

CSRF

CORS

Same-Origin Policy

Content Security Policy

Rate Limiting

Input Validation

SQL Injection

Principle of Least Privilege

Part 8: Performance and Scaling

Cache

Browser Cache

CDN

Load Balancer

Reverse Proxy

Horizontal Scaling

Vertical Scaling

Availability

Latency

Throughput

Part 9: Real-Time and Asynchronous Communication

Polling

Long Polling

Server-Sent Events

WebSockets

Queue

Worker

Message Broker