terms.txt

========== WEBSITE & HOSTING ==========
Frontend        — The part you see and click on (browser)
Backend         — The part that thinks and decides (server)
Database (DB)    — Where all data lives forever (MySQL)
Redis            — A fast temporary memory for often-used data
Cache            — Storing stuff in Redis so you don't hit the slow database
VPS              — A rented computer that's always on ($3-4/mo)
Docker           — A tool to package your app so it runs the same everywhere
API              — A way for frontend to talk to backend
Server           — Any computer that's always on and connected to internet
Hosting          — Renting space on someone else's server
Deploy           — Uploading your code to a server so the world can use it
Connection pool  — A batch of pre-opened database connections for speed
Concurrent users — Number of people using your site at the exact same moment
Query            — A question you ask the database (e.g., "find all whey proteins")

========== WEB TECHNOLOGIES ==========
HTML        — The structure of a webpage (headings, paragraphs, images)
CSS         — The styling of a webpage (colors, fonts, layout)
JavaScript  — The programming language that makes webpages interactive
TypeScript  — JavaScript with extra safety features to catch bugs early
Node.js     — A way to run JavaScript on a server instead of a browser
React       — A library for building interactive frontend UIs
Next.js     — A framework built on React that handles routing, API, and more
Framework   — A pre-built structure that saves you from writing everything from scratch
Library     — A collection of reusable code you can plug into your project
Package     — A chunk of code someone else wrote that you can download and use
npm         — A marketplace and installer for JavaScript packages

========== API & NETWORKING ==========
API route     — A special URL on your backend that returns data instead of a webpage
JSON          — A simple text format to send data between frontend and backend
REST          — A standard way to design API routes (GET, POST, PUT, DELETE)
HTTP          — The protocol browsers use to talk to servers
HTTPS         — HTTP but encrypted (the lock icon in your browser)
URL           — The web address you type in the browser (amazon.com)
Domain        — The human-readable name of a website (google.com)
DNS           — The phonebook that converts domain names to server IP addresses
IP address    — The numerical address of a server on the internet
Port          — A numbered door on a server (3306 = MySQL, 80 = HTTP, 443 = HTTPS)
Environment variable — Secret values stored outside your code (passwords, API keys)
.env file     — A local file that holds your environment variables

========== DATABASE TERMS ==========
ORM          — A tool that lets you talk to the database using code instead of writing SQL
SQL          — The language used to talk to relational databases
Table        — A collection of related data in a database (like an Excel sheet)
Row          — A single record in a database table (one product, one user)
Column       — A single field in a database table (name, price, category)
Primary key  — A unique ID that identifies each row in a table
Foreign key  — A column that links one table to another (product → brand)
Index        — A speed-boost for database searches (like a book's index)
Migration    — A script that changes your database schema over time
Schema       — The structure/blueprint of your database (tables, columns, relationships)
Seed         — Adding initial data to a fresh database (categories, retailers)
Transaction  — A group of database operations that must all succeed or all fail together
JOIN         — Combining data from two or more tables in a single query
Trigger      — An automatic action that runs when something happens in the database
Stored procedure — A saved set of SQL commands you can call by name

========== DEVELOPMENT ==========
index.html     — The default file a web server serves when you visit a URL
localhost      — A special address that points to your own computer
Production     — The live version of your website that real users see
Development    — The version you work on locally on your computer
Staging        — A test version that mirrors production for final testing
CI/CD          — Automatic testing and deployment when you push code (GitHub Actions)

========== GIT & GITHUB ==========
Git           — A tool that tracks changes to your code over time
GitHub        — A website that stores your Git repositories in the cloud
Repository    — A folder containing your project with full version history
Commit        — A saved snapshot of your code at a point in time
Branch        — A separate version of your code for working on features safely
Merge         — Combining changes from one branch into another
Pull request  — A request to merge your changes, often reviewed by teammates
Push          — Uploading your local commits to GitHub
Pull          — Downloading the latest changes from GitHub to your computer
Clone         — Downloading a whole repository for the first time
SSH key       — A secure way to authenticate to GitHub without a password

========== BUILD & DEPLOY ==========
Build           — Converting your source code into optimized production files
Compile         — Converting human-readable code into machine-executable code
Minify          — Removing unnecessary characters from code to make it load faster
Bundle          — Combining many small files into fewer larger files for faster loading
CDN             — A network of servers around the world that serve static files fast
Load balancer   — A tool that distributes incoming traffic across multiple servers
Scaling         — Adding more servers when traffic increases
Horizontal scaling — Adding more machines to handle more users
Vertical scaling   — Giving a single machine more RAM/CPU
Latency         — The time it takes for data to travel from point A to point B
Bandwidth       — How much data can be transferred per second
Throughput      — How many requests your system can handle per second
Rate limiting   — Blocking users who make too many requests too fast

========== AUTHENTICATION & SECURITY ==========
Authentication  — Verifying who a user is (login/password)
Authorization   — Verifying what a user is allowed to do
JWT             — A token that proves a user is logged in without asking for password again
Session         — A temporary record of a logged-in user stored on the server
Cookie          — A small piece of data stored in the browser to remember you
OAuth           — Logging in with Google/Facebook/GitHub instead of a password
Middleware      — Code that runs between the request and the response (checking auth, logging)
Webhook         — A URL that another service calls when something happens (payment confirmed)
WebSocket       — A persistent connection for real-time data (chat, live notifications)

========== RENDERING ==========
SSR     — Server-Side Rendering — generating the HTML on the server before sending it
SSG     — Static Site Generation — pre-building HTML pages at build time
CSR     — Client-Side Rendering — generating HTML in the browser using JavaScript
ISR     — Incremental Static Regeneration — SSG but pages rebuild when data changes

========== SEO & ANALYTICS ==========
SEO          — Making your site rank higher in Google search results
Meta tags    — Hidden HTML tags that tell Google what your page is about
Sitemap      — An XML file listing all pages on your site for Google
Analytics    — Tracking how many users visit and what they do
A/B testing  — Showing two versions of a page to see which performs better

========== HTTP BASICS ==========
CRUD        — Create, Read, Update, Delete — the four basic data operations
SSL/TLS     — The technology that encrypts data between browser and server
CORS        — A security mechanism that blocks one website from calling another
CSRF        — A type of attack where a malicious site makes requests on your behalf
XSS         — A type of attack where malicious code is injected into a webpage
SQL injection — A type of attack where malicious SQL is injected via user input
Sanitize    — Cleaning user input to remove dangerous content
Validate    — Checking that user input meets requirements (valid email, not empty)

========== CODING CONCEPTS ==========
Logging        — Recording events (errors, requests) for debugging
Debugging      — Finding and fixing bugs in your code
Error handling — Code that gracefully handles failures instead of crashing
Try/catch      — A pattern to catch and handle errors without crashing
Throw          — Deliberately creating an error in your code
Promise        — A JavaScript object representing a future value (async operation)
Async/await    — A cleaner way to write code that waits for something (database, API)
Callback       — A function passed to another function to run later
Event loop     — The mechanism by which Node.js handles multiple tasks without blocking
Blocking       — Code that stops everything else from running until it finishes
Non-blocking   — Code that lets other things run while waiting (async)

========== DOCKER ==========
Container      — A lightweight, isolated environment to run an application
Image          — A snapshot of a container's filesystem (blueprint for containers)
Dockerfile     — A recipe file that defines how to build a Docker image
docker-compose — A tool to run multiple containers together (MySQL + Redis + your app)
Volume         — Persistent storage for Docker containers (data survives restart)
Port mapping   — Connecting a container port to your computer port (-p 3306:3306)

========== SYSTEM ADMIN ==========
Environment  — The context your app runs in (local, staging, production)
Config       — Settings that change between environments (database URLs, API keys)
CLI          — Command Line Interface — typing commands instead of clicking buttons
GUI          — Graphical User Interface — clicking buttons instead of typing commands
Terminal     — The black window where you type commands
Shell        — The program inside the terminal that interprets your commands (bash, zsh)
PATH         — A list of folders your terminal searches when you type a command
Process      — A running program on your computer or server
Daemon       — A background process that keeps running (MySQL, Redis)
PID          — Process ID — a number that identifies a running process
Cron job     — A scheduled task that runs automatically (backup every night at 2 AM)
Crontab      — The file that lists all cron jobs
systemd      — The Linux system that starts/stops services on boot
Swap         — Using hard drive space as extra RAM when memory is full

========== HARDWARE ==========
SSD  — A fast type of hard drive (no moving parts)
RAM  — Temporary memory your computer uses for active tasks
CPU  — The processor — the brain that executes instructions
vCPU — A virtual CPU core on a VPS
Uptime — How long a server has been running without restart
SLA    — A guarantee from a provider about uptime percentage (99.9%)

========== FILE STORAGE ==========
S3          — Amazon's cloud storage service (for images, backups, files)
Cloudinary  — A service that hosts and transforms images for you
ImgBB       — A free image hosting service
WebP        — A modern image format that's smaller than PNG/JPEG
Lazy loading — Loading images only when they're about to appear on screen

========== UI/UX ==========
Pagination     — Splitting a long list into pages (1, 2, 3...)
Infinite scroll — Loading more items as the user scrolls down
Debounce       — Waiting until the user stops typing before searching (search box)
Throttle       — Limiting how often a function can run (scroll event)
Polyfill       — Code that adds modern features to old browsers
Transpile      — Converting modern JavaScript to older JavaScript for compatibility
Tree shaking   — Removing unused code during the build to reduce file size
Hot reload     — Automatically updating the browser when you save code changes

========== CODE QUALITY ==========
Linting     — Automatically checking your code for errors and style issues
Prettier    — A tool that automatically formats your code consistently
ESLint      — A tool that catches bugs and style problems in JavaScript
Husky       — A tool that runs checks before you commit code
Semver      — A version numbering system: major.minor.patch (2.1.0)
Breaking change — A new version that requires you to change your code
Deprecated  — A feature that still works but is scheduled for removal
Legacy      — Old code that still works but is no longer maintained
Refactor    — Rewriting code to be better without changing what it does
Technical debt — Shortcuts in code that will need fixing later
Spaghetti code — Messy, tangled code that's hard to understand
Boilerplate — Repetitive code that needs to be written for many features

========== ARCHITECTURE ==========
Monolith        — One big application that does everything
Microservices   — Many small applications that each do one thing and talk to each other
Serverless      — Running code without managing a server (Vercel, AWS Lambda)
Edge function   — Code that runs in CDN data centers closest to the user
JAMstack        — A modern architecture: JavaScript + APIs + pre-built HTML
MVC             — Model-View-Controller — a pattern to organize code
Singleton       — A single shared instance of something (database connection pool)
Dependency injection — Passing dependencies into a class instead of creating them inside
Factory pattern — A function that creates and returns objects
Observer pattern — One thing notifies many others when something happens
Pub/sub         — Publish/Subscribe — senders and receivers don't know each other

========== COMMUNICATION PATTERNS ==========
Webhook     — An HTTP callback — service A calls service B when something happens
WebSocket   — Two-way real-time communication channel
SSE         — Server-Sent Events — server pushes data to browser one-way
Polling     — Asking the server repeatedly for new data (inefficient)
Rate limit  — Max requests per minute/second a server allows

========== HTTP STATUS CODES ==========
200 — "OK" — everything worked
201 — "Created" — a new resource was created
301 — "Moved Permanently" — the URL has changed
304 — "Not Modified" — use your cached version
400 — "Bad Request" — you sent something the server didn't understand
401 — "Unauthorized" — you need to log in first
403 — "Forbidden" — you're logged in but not allowed to do this
404 — "Not Found" — the page/URL doesn't exist
429 — "Too Many Requests" — you hit the rate limit
500 — "Internal Server Error" — something broke on the server
502 — "Bad Gateway" — server got an invalid response from another server
503 — "Service Unavailable" — server is temporarily down or overloaded
504 — "Gateway Timeout" — one server waited too long for another

========== COMPUTER SCIENCE CONCEPTS ==========
Idempotent  — An operation that produces the same result no matter how many times you run it
Stateful    — The server remembers information about the user between requests
Stateless   — Each request is independent — server doesn't remember previous ones
Hashing     — Converting data into a fixed-length string that can't be reversed (passwords)
Encryption  — Scrambling data so only someone with the key can read it
Salt        — Random data added to a password before hashing to make it more secure
Plaintext   — Readable, unencrypted text (bad for passwords)
Base64      — A way to encode binary data (images) as text for transfer
UTF-8       — A character encoding that supports all languages and emojis
ASCII       — A basic character encoding for English letters, numbers, and symbols
Unicode     — A standard that assigns a unique number to every character in every language
Regex       — A pattern for matching text (finding emails, phone numbers in strings)

========== JAVASCRIPT DATA TYPES ==========
Boolean    — A value that is either true or false
Null       — No value — intentionally empty
Undefined  — A variable that was declared but never given a value
NaN        — "Not a Number" — a result of an invalid math operation
Array      — An ordered list of items [1, 2, 3]
Object     — A collection of key-value pairs {name: "John", age: 30}
String     — A piece of text — "hello world"
Number     — A numeric value — 42, 3.14
Integer    — A whole number — 42, no decimals
Float      — A number with decimals — 3.14

========== JAVASCRIPT FUNDAMENTALS ==========
Function       — A reusable block of code that does one thing
Parameter      — A variable a function receives when called
Argument       — The actual value you pass to a function when calling it
Return value   — The output a function gives back
Scope          — Where a variable is accessible in your code (inside/outside functions)
Global         — A variable accessible from anywhere in your code
Local          — A variable accessible only within a specific function or block
Closure        — A function that remembers variables from where it was created
Recursion      — A function that calls itself (like Russian nesting dolls)
Loop           — Repeating an action multiple times (for, while)
Conditional    — Code that runs only if something is true (if/else)
Switch         — A cleaner way to write many if/else conditions for one value
Iteration      — One cycle of a loop
Infinite loop  — A loop that never ends (crashes your program)
Break          — Exiting a loop early
Continue       — Skipping the rest of the current loop iteration and moving to the next
Variable       — A named container that holds a value
Constant       — A variable that cannot be changed after being set
Data type      — The kind of value (string, number, boolean, object, array)

========== JAVASCRIPT OPERATORS ==========
Template literal — A JavaScript string with embedded variables using backticks
Concatenation    — Joining strings together — "Hello " + "World"
Interpolation    — Inserting variables directly into a string — `${name}`
Operator         — A symbol that performs an operation — +, -, *, /, =
Comparison       — Checking if two values are equal/not equal/greater/less
Logical operator — Combining conditions — && (AND), || (OR), ! (NOT)
Ternary          — A shorthand if/else — condition ? valueIfTrue : valueIfFalse
Spread operator  — Expanding an array or object into individual elements — ...arr
Destructuring    — Extracting values from arrays/objects into variables in one line
Optional chaining — Safely accessing nested properties without crashing — ?.
Nullish coalescing — Using a default value only if null/undefined — ??

========== MODULES & PACKAGES ==========
Module         — A file that exports code for other files to import
Import         — Bringing code from another file into the current file
Export         — Making code available for other files to use
Default export — The main thing a module exports
Named export   — A specific named thing a module exports
Package.json   — The file that describes your project and its dependencies
Node_modules   — The folder where all downloaded packages live
Dependency     — A package your project needs to work
Dev dependency — A package needed only during development (not in production)
Peer dependency — A package your project expects the host project to provide
Lock file      — A file that locks exact versions of every dependency
Caret (^)      — Allow minor and patch updates but not major ones
Tilde (~)      — Allow only patch updates
Script         — A command defined in package.json that you can run with npm run

========== PACKAGE MANAGERS ==========
npx     — A tool that runs a package without installing it globally
Global install — Installing a package so it's available everywhere on your system
Local install  — Installing a package only for the current project
Monorepo       — A single repository containing multiple projects/packages
Workspace      — A way to manage multiple packages in one repository
pnpm           — A faster, disk-space-efficient alternative to npm
Yarn           — Another alternative to npm (similar but different)
Bun            — A super-fast JavaScript runtime that also replaces npm
Runtime        — The program that executes your code (Node.js, Bun, Deno)
Deno           — A modern JavaScript runtime made by the creator of Node.js

========== CODE PATTERNS ==========
Polyfill    — Code that adds a missing feature to older environments
Shim        — A small piece of code that intercepts and modifies behavior
Wrapper     — Code that adds functionality around an existing function or library
Adapter     — Code that lets two incompatible things work together
Plugin      — Additional code that extends the functionality of a tool
Extension   — Same as plugin — adds features to a browser or editor
Interceptor — Code that "catches" requests or responses to modify them
Guard       — Code that checks conditions before allowing access (auth guard)
Service     — A reusable class or module that handles a specific business operation
Controller  — In MVC, the part that handles incoming requests and returns responses

========== ROUTING ==========
Route          — A URL pattern mapped to a specific handler function
Router         — Code that matches URLs to their handlers
Handler        — The function that processes a request for a specific route
Endpoint       — A specific URL that accepts API requests
Query string   — Extra data appended to a URL — ?search=phone&page=2
Path parameter — A variable in the URL path — /products/:id
Request body   — Data sent with a POST/PUT request (usually JSON)
Request headers — Metadata sent with a request (auth tokens, content type)
Response headers — Metadata the server sends back (caching info, content type)

========== HTTP HEADERS ==========
Content-Type      — Header that tells what format the data is in (application/json)
Authorization     — Header that carries authentication tokens (Bearer <token>)
User-Agent        — Header that identifies the client (browser, mobile app)
Status code       — A number indicating the result of an HTTP request (200, 404, 500)

========== HTTP METHODS ==========
GET     — HTTP method to retrieve data (read)
POST    — HTTP method to create new data (write)
PUT     — HTTP method to replace data entirely (update)
PATCH   — HTTP method to partially update data
DELETE  — HTTP method to remove data
HEAD    — HTTP method to get headers only, no body
OPTIONS — HTTP method to check what methods are allowed (CORS preflight)

========== BACKGROUND JOBS ==========
CRON              — Scheduled tasks (midnight backup, daily email)
Batch             — Processing many items together instead of one by one
Queue             — A list of tasks waiting to be processed (sending emails, resizing images)
Worker            — A process that picks up and completes tasks from a queue
Job               — A single unit of work in a queue
Dead letter queue — A queue for failed jobs that need manual inspection

========== RESILIENCE ==========
Rate limiter       — Prevents too many requests from the same user in a short time
Circuit breaker    — Stops calling a failing service to prevent cascading failures
Retry              — Trying an operation again after it fails
Exponential backoff — Increasing wait time between retries (1s, 2s, 4s, 8s...)
Timeout            — Giving up on an operation if it takes too long
Health check       — A simple endpoint that tells if your service is alive (/api/health)
Probe              — An automated check that monitors if a service is healthy
Heartbeat          — A periodic signal that says "I'm still alive"

========== NETWORKING ==========
Firewall     — Software that blocks unwanted network traffic
Proxy        — An intermediary server between client and destination
Reverse proxy — A server that sits in front of your app (Nginx, Caddy)
Nginx        — A popular web server and reverse proxy (pronounced "engine-x")
Caddy        — A simpler web server with automatic HTTPS
Apache       — Another popular web server (older than Nginx)

========== SSL / HTTPS ==========
SSL certificate      — A file that enables HTTPS on your domain
Let's Encrypt        — A free automated SSL certificate provider
Certbot              — A tool that automatically gets and renews Let's Encrypt certificates
Wildcard certificate — An SSL cert that covers all subdomains (*.yoursite.com)
Self-signed certificate — An SSL cert you create yourself (dev only, not trusted by browsers)
HTTPS redirect       — Automatically sending HTTP traffic to HTTPS
HSTS                 — A header that tells browsers to always use HTTPS for your site

========== SECURITY THREATS ==========
DDoS — Distributed Denial of Service — overwhelming a server with traffic to take it down
Bot  — An automated program that visits websites (good: Googlebot, bad: scrapers)

========== SEARCH ENGINES ==========
Crawler       — A bot that systematically visits pages to index them (Google, Bing)
Robots.txt    — A file that tells crawlers which pages they can/can't visit
Sitemap.xml   — A file that lists all pages on your site for search engines
Canonical URL — The official URL for a page when duplicate content exists
Noindex       — A meta tag that tells Google not to include a page in search results
Nofollow      — A link attribute that tells Google not to pass SEO value
Open Graph    — Meta tags that control how your page looks when shared on social media
Schema.org    — Structured data markup that helps Google understand your content
Rich snippet  — Enhanced Google search results with stars, prices, images

========== ACCESSIBILITY ==========
ALT text       — Descriptive text for images (accessibility + SEO)
Accessibility  — Making your site usable by people with disabilities
ARIA           — HTML attributes that improve accessibility for screen readers
Screen reader  — Software that reads webpages aloud for visually impaired users
Contrast ratio — The difference between text color and background color

========== RESPONSIVE DESIGN ==========
Responsive design — A website that looks good on all screen sizes (phone, tablet, desktop)
Mobile-first      — Designing for mobile first, then adding features for larger screens
Breakpoint        — A screen width where the layout changes (768px, 1024px)
Media query       — CSS code that applies only at certain screen sizes
Flexbox           — A modern CSS layout system for one-dimensional arrangements
Grid              — A modern CSS layout system for two-dimensional arrangements
Viewport          — The visible area of a web page in the browser
Above the fold    — Content visible without scrolling
Below the fold    — Content that requires scrolling to see

========== PERFORMANCE METRICS ==========
FCP  — First Contentful Paint — when the first content appears on screen
LCP  — Largest Contentful Paint — when the main content loads
FID  — First Input Delay — how quickly the page responds to first click
CLS  — Cumulative Layout Shift — how much the page jumps around while loading
Core Web Vitals — Google's three metrics for user experience (LCP, FID, CLS)
TTFB — Time to First Byte — how long until the server starts responding

========== REACT FUNDAMENTALS ==========
DOM              — Document Object Model — the browser's internal representation of your HTML
Virtual DOM      — React's lightweight copy of the DOM used for fast updates
Hydration        — React attaching event handlers to pre-rendered HTML on page load
Reconciliation   — React's process of figuring out what changed and updating only that
Component        — A reusable piece of UI (button, card, navbar)
Props            — Data passed from parent component to child component
State            — Data that a component remembers and can change over time
Hook             — A React function that lets you use state and other features in components

========== REACT HOOKS ==========
useState     — React hook that creates a state variable
useEffect    — React hook that runs code when component mounts or updates
useContext   — React hook that accesses global data without passing props
useReducer   — React hook for complex state logic (like Redux-lite)
useRef       — React hook that holds a mutable value without causing re-renders
useMemo      — React hook that caches a computed value for performance
useCallback  — React hook that caches a function for performance
Custom hook  — Your own reusable hook combining built-in hooks

========== REACT PATTERNS ==========
Higher-order component — A function that takes a component and returns an enhanced version
Render prop            — A prop that is a function returning JSX
Children prop          — A special prop that contains content between component tags
Key prop               — A unique identifier React uses to track list items
Fragment               — An empty wrapper that doesn't add extra DOM nodes (<>...</>)
Portal                 — Rendering a component outside its parent DOM hierarchy
Context                — React's way to share global data without prop drilling
Prop drilling          — Passing data through many nested component layers

========== REACT FORMS ==========
Controlled component   — A form input whose value is controlled by React state
Uncontrolled component — A form input that manages its own value (ref)
Synthetic event        — React's cross-browser wrapper around native browser events
Event bubbling         — An event propagating from child element up to parent elements
Event delegation       — Attaching one event listener to a parent instead of many children

========== PERFORMANCE OPTIMIZATION ==========
Debounce         — Delaying an action until after a pause (search while typing)
Throttle         — Limiting how often an action can fire (scroll handler)
Memoization      — Caching a function's result so it doesn't recompute
Lazy loading     — Loading code/components only when they're needed
Code splitting   — Breaking your bundle into smaller chunks loaded on demand
Dynamic import   — Importing code at runtime instead of at the top of a file
Suspense         — React's way to show a fallback while waiting for async data
Error boundary   — A React component that catches errors in its children
Strict mode      — React's development mode that double-invokes functions to find bugs
Ref              — A way to access DOM elements directly in React
Forward ref      — Passing a ref through a component to a child element

========== STATE MANAGEMENT ==========
Flux          — An architecture pattern where data flows in one direction (Redux)
Redux         — A popular state management library for React
Store         — The single object that holds all global state in Redux
Action        — A plain object describing what happened (type: "ADD_TODO")
Reducer       — A pure function that takes current state + action → returns new state
Dispatch      — Sending an action to the store to trigger a state change
Selector      — A function that extracts specific data from the Redux store
Slice         — A portion of the Redux store with its own reducer and actions
Thunk         — A function that delays an action (for async operations in Redux)
Saga          — A more powerful way to handle side effects in Redux (generators)
Zustand       — A simpler, smaller alternative to Redux for state management
Jotai         — An atomic state management library (like Recoil but simpler)
Recoil        — Facebook's state management library with atoms and selectors

========== DATA FETCHING ==========
TanStack Query  — A library that manages server state (caching, refetching)
SWR             — A React hook library for data fetching (stale-while-revalidate)
Mutation        — A data change operation (create, update, delete)
Invalidation    — Marking cached data as stale so it refetches
Optimistic update — Updating the UI immediately before the server confirms
Pessimistic update — Waiting for server confirmation before updating the UI

========== REAL-TIME ==========
Polling    — Repeatedly fetching data at an interval
WebSocket  — A persistent two-way connection for real-time data
SSE        — Server-Sent Events — server pushes data to the client (one-way)

========== API STYLES ==========
REST    — Representational State Transfer — the standard API architecture
GraphQL — A query language where the client asks for exactly the data it needs
Query   — A GraphQL read operation (equivalent to GET)
Mutation — A GraphQL write operation (equivalent to POST/PUT/DELETE)
Subscription — A GraphQL real-time operation (equivalent to WebSocket)
Schema  — In GraphQL, the definition of all available types and operations
Resolver — A function that fetches the data for a GraphQL field
Apollo  — The most popular GraphQL client and server library
Relay   — Facebook's GraphQL client (more optimized, harder to learn)
tRPC    — A framework for building fully-typesafe APIs without GraphQL
gRPC    — A high-performance RPC framework by Google (alternative to REST)
RPC     — Remote Procedure Call — calling a function on another server
SOAP    — An older XML-based API protocol (rare today)

========== CLOUD PLATFORMS ==========
Vercel      — A platform that hosts Next.js apps with serverless functions
Netlify     — Another hosting platform for frontend apps
AWS         — Amazon Web Services — the biggest cloud provider
Lambda      — AWS's serverless function service
EC2         — AWS's virtual server service (like a VPS)
S3          — AWS's storage service (files, images, backups)
CloudFront  — AWS's CDN service
RDS         — AWS's managed database service
DynamoDB    — AWS's NoSQL database
Route53     — AWS's DNS service
ECS         — AWS's container service (Docker)
EKS         — AWS's Kubernetes service
IAM         — AWS's identity and access management
CloudWatch  — AWS's monitoring and logging service
GCP         — Google Cloud Platform
Azure       — Microsoft's cloud platform
DigitalOcean — A simpler, cheaper cloud provider ($5 VPS)
Lightsail    — AWS's simplified VPS (like DigitalOcean)
Vultr        — Another VPS provider (competitive pricing)
Linode       — Another VPS provider (now part of Akamai)
Hetzner      — German VPS provider (very cheap, excellent value)
Fly.io       — A platform that runs your app close to users globally
Railway      — A simple deployment platform with free tiers
Render       — A simple hosting platform with free tiers

========== ORCHESTRATION ==========
Kubernetes   — A system for automatically managing many containers
Docker Swarm — Docker's built-in container orchestration (simpler than K8s)
Nomad        — HashiCorp's simpler alternative to Kubernetes
Pod          — The smallest deployable unit in K8s (one or more containers)
Node         — A machine in a Kubernetes cluster
Cluster      — A group of nodes managed by Kubernetes
Deployment   — A K8s resource that manages replica pods
Service      — A stable network endpoint for a set of pods
Ingress      — Rules for routing external traffic to services
ConfigMap    — A way to store non-sensitive configuration
Secret       — A way to store sensitive data (passwords, keys)
Namespace    — A virtual cluster within a physical cluster
Helm         — A package manager for Kubernetes
Chart        — A Helm package (collection of K8s YAML files)
Kustomize    — A built-in K8s tool to customize YAML without templates
Operator     — A K8s extension that manages complex applications
CRD          — Custom Resource Definition — extending the K8s API
Sidecar      — An extra container in a pod that supports the main container
Init container — A container that runs to completion before the main app starts
DaemonSet    — A K8s resource that runs one pod on every node
StatefulSet  — A K8s resource for stateful applications (databases)
PV           — PersistentVolume — storage resource in K8s
PVC          — PersistentVolumeClaim — a request for storage
StorageClass — A K8s resource that defines different storage types (ssd, hdd)
HPA          — Horizontal Pod Autoscaler — automatically scales pods
VPA          — Vertical Pod Autoscaler — automatically adjusts CPU/RAM
PDB          — Pod Disruption Budget — minimum pods that must stay up
RBAC         — Role-Based Access Control — who can do what in K8s
ServiceAccount — An identity for a pod to use when calling the K8s API

========== SERVICE MESH ==========
Istio    — A service mesh that manages traffic between microservices
Envoy    — A high-performance proxy used by service meshes (Istio)
Linkerd  — A simpler, lighter service mesh alternative to Istio
mTLS     — Mutual TLS — both sides verify each other's identity

========== INFRASTRUCTURE AS CODE ==========
Terraform — A tool to define infrastructure as code
Ansible   — A tool for automating server setup and configuration
Puppet    — Another configuration management tool
Chef      — Another configuration management tool

========== DOCKER ADVANCED ==========
Multi-stage build — Using multiple FROM statements to keep final image small
Alpine    — A minimal Linux distribution (~5 MB) used for small Docker images
Distroless — Docker images that contain only your app and its runtime
Entrypoint — The command that runs when a container starts
CMD       — Default arguments for the entrypoint
EXPOSE    — Documentation that the container listens on a port
VOLUME    — A persistent storage mount for a container
Bind mount — Mounting a host directory into a container (for live development)
Tmpfs mount — A temporary in-memory mount (fast, lost on restart)
Docker network — A virtual network connecting containers
Bridge network — The default Docker network (containers can see each other)
Host network — Container uses the host's network directly (no isolation)
docker-compose.yml — A YAML file defining multiple services (app, db, redis)
Service   — A container defined in docker-compose (web, database, cache)
Healthcheck — A command Docker runs to check if a container is healthy
Restart policy — What Docker does when a container stops (always, unless-stopped)
Orphan container — A container no longer defined in docker-compose
Dangling image — An untagged image taking up disk space
Prune     — Cleaning up unused Docker resources (images, containers, volumes)
Registry  — A place to store and share Docker images (Docker Hub, GHCR)
Docker Hub — The default public Docker image registry
GHCR      — GitHub Container Registry
Tag       — A label for a Docker image (mysql:8, myapp:latest)
Digest    — A unique SHA256 identifier for a specific Docker image

========== OBSERVABILITY ==========
Observability — The ability to understand what your system is doing
Metrics   — Numerical measurements (CPU, request count, error rate)
Logs      — Text records of events (errors, requests, debug info)
Traces    — Following a request through multiple services
Distributed tracing — Tracing a request across microservices
Jaeger    — An open-source distributed tracing tool
Zipkin    — Another distributed tracing tool (older)
OpenTelemetry — A unified standard for collecting telemetry data
Prometheus — A popular open-source monitoring and alerting system
Grafana   — A dashboard tool for visualizing metrics from Prometheus
Alertmanager — A Prometheus component that sends alerts (email, Slack)
Datadog   — A paid observability platform (logs, metrics, traces)
New Relic — Another paid observability platform
Sentry    — An error tracking service (free tier available)
ELK Stack — Elasticsearch + Logstash + Kibana (logging)
Elasticsearch — A search and analytics engine (part of ELK)
Logstash  — A log processing pipeline (part of ELK)
Kibana    — A visualization dashboard for Elasticsearch (part of ELK)
Loki      — Grafana's log aggregation system (like Prometheus but for logs)
Tempo     — Grafana's distributed tracing backend
PagerDuty — An on-call alerting service (wakes you up at 3 AM)
Slack     — Chat platform where many dev teams get alerts

====================================================================================================
= AMAZON — HOW THE BIGGEST WEBSITE IN THE WORLD ACTUALLY WORKS (EVERY TECHNOLOGY INVOLVED)
====================================================================================================
This is a step-by-step walkthrough of what happens when you type "amazon.com" and buy a product.
Every bolded term is defined in the glossary above. This shows how all the pieces fit together.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 1: YOU TYPE "amazon.com" IN YOUR BROWSER
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. Your browser checks its cache for a recent copy of amazon.com → If found, load instantly
2. No cache → Browser asks DNS (Route53 on AWS) to convert "amazon.com" to an IP address
3. DNS returns multiple IP addresses (load balancing) from different AWS regions
4. Browser picks the closest IP and connects via HTTPS (SSL certificate from AWS Certificate Manager)
5. The connection goes through a Firewall (AWS WAF — Web Application Firewall) that blocks attacks
6. Request hits CloudFront (Amazon's CDN) — serves static files from the nearest edge location
7. If the page is cached at the CDN edge, it returns instantly without touching the main servers
8. If not cached → request goes to the Load Balancer (ELB — Elastic Load Balancer)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 2: THE LOAD BALANCER DECIDES WHERE TO SEND YOU
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

9. ELB receives your request — it's the entry point to Amazon's backend
10. ELB checks which backend servers are healthy (Health check) and have capacity
11. If traffic is high, Auto-scaling (HPA — Horizontal Pod Autoscaler) has already spawned more servers
12. ELB forwards your request to one of thousands of microservices running on EC2 or EKS (Kubernetes)
13. The specific microservice that handles "product page" is called the "Product Service"

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 3: THE PRODUCT SERVICE BUILDS YOUR PAGE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

14. Your browser sent a GET request to the API endpoint: /gp/product/B08N5WRWNW
15. Before processing, the API Gateway checks: Authentication? (JWT token in cookie/header)
    Authorization? (are you allowed to see this product?)
16. The Product Service microservice (written in Java — Amazon's primary backend language)
    starts gathering data from at least 12 different internal services:

    a) Calls Product Catalog Service (DynamoDB) → product name, description, images
    b) Calls Pricing Service (Aurora/MySQL) → current price, original price, discounts
    c) Calls Inventory Service (DynamoDB) → is it in stock? how many left?
    d) Calls Review Service (DynamoDB + Elasticsearch) → ratings, reviews, star breakdown
    e) Calls Image Service (S3 + CloudFront) → product photo URLs
    f) Calls Offer Service (DynamoDB) → deals, coupons, lightning deals
    g) Calls Recommendation Service (ML model on SageMaker) → "Frequently bought together"
    h) Calls Seller Service (DynamoDB) → who's selling it, seller rating
    i) Calls Shipping Service (custom DB) → delivery date estimate based on your zip code
    j) Calls Tax Service → applicable taxes
    k) Calls Ad Service → sponsored product ads to show on the page
    l) Calls Personalization Service (ML) → "Based on your browsing history" section

17. Each of these calls goes to different microservices — some are in the same data center,
    others are in different AWS regions (Distributed architecture)
18. These inter-service calls use gRPC (fast) and REST (for external) protocols
19. The calls pass through Istio (Service Mesh) which handles:
    - mTLS (encryption between services)
    - Rate limiting (prevent one service from overwhelming another)
    - Circuit breaker (if a service fails, stop calling it)
    - Distributed tracing (trace the request across services — OpenTelemetry + X-Ray)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 4: CACHING LAYER (BEFORE HITTING THE DATABASE)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

20. Before each service queries its database, it checks Redis/Memcached first (the cache layer)
21. Product details for bestsellers are cached in Redis with TTL (Time To Live)
22. If cached → return instantly (single millisecond)
23. If not cached → query the database, then store result in Redis for next time
24. Redis also stores: user sessions, shopping cart contents, rate limit counters
25. This is why popular products load fast even during Black Friday — they're cached

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 5: DATABASES (THE MANY KINDS AMAZON USES)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

26. Amazon doesn't use one database — it uses many, each for a specific purpose:

    DynamoDB (NoSQL) — Used for: product catalog, customer profiles, shopping carts, orders,
    seller data, session data. Reason: needs to handle millions of reads/writes per second.
    It's Amazon's own database — serverless, auto-scaling.

    Aurora (MySQL-compatible, RDS) — Used for: pricing data, financial records, inventory
    counts, affiliate data. Reason: needs ACID transactions, complex JOINs, data integrity.

    ElastiCache (Redis) — Used for: caching product pages, sessions, rate limiting, leaderboards.
    Reason: sub-millisecond reads, never used as primary storage.

    OpenSearch (Elasticsearch) — Used for: product search, auto-complete suggestions,
    log analytics. Reason: full-text search is bad in SQL databases.

    S3 (Object storage) — Used for: product images, user-uploaded photos, backups,
    logs, static assets, ML training data. Reason: cheap, infinitely scalable, 99.999999999% durable.

    Timestream — Used for: time-series data like price history, stock levels over time.
    Reason: optimized for time-based queries.

    QLDB (Ledger Database) — Used for: immutable audit logs of financial transactions.
    Reason: records cannot be modified or deleted — for accounting compliance.

27. Data is replicated across multiple AWS Availability Zones (different physical data centers)
    so if one data center goes down, no data is lost.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 6: SEARCH — HOW SEARCHING "iphone 15" WORKS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

28. As you type in the search box, the frontend uses Debounce (waits 300ms after you stop typing)
29. It sends each keystroke to the auto-complete API (OpenSearch) → suggests "iphone 15", "iphone 15 pro"
30. When you press Enter, it sends a GET request to /s?k=iphone+15
31. The Search Service (microservice) sends the query to OpenSearch with:
    - Full-text search on product titles, descriptions, categories
    - Filtering by category, price range, brand, prime eligibility
    - Faceting (count of results in each category)
    - Spelling correction ("iphon" → "Did you mean: iphone?")
    - Ranking based on relevance, price, reviews, sales velocity
32. Results are merged with Ad Service results (sponsored products)
33. Results are paginated (Pagination) — 16 products per page
34. Returns JSON to the frontend → React renders the product grid

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 7: THE FRONTEND (WHAT YOU SEE IN YOUR BROWSER)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

35. Amazon invented React — their entire UI is built with React components
36. The HTML you first receive is Server-Side Rendered (SSR) via their internal Node.js layer
37. Then React Hydrates — attaches event handlers to the pre-rendered HTML
38. The page is split into components:
    - Navbar (search bar, cart count, sign-in status)
    - Product image gallery (carousel with zoom)
    - Buy box (price, delivery date, add to cart button)
    - Description tab
    - Reviews section
    - Recommendation carousels
39. Components use lazy loading (code splitting) — reviews and recommendations load after the main content
40. Images use lazy loading — only images near your viewport load first
41. Images are served in WebP format (smaller, faster) with fallback to JPEG for old browsers
42. CSS is minified and bundled into a single file
43. JavaScript is also bundled and tree-shaken (unused code removed)
44. The entire page is A/B tested — you might see a different layout than your neighbor
45. Metrics like LCP, FID, CLS (Core Web Vitals) are tracked for every page load

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 8: ADDING TO CART
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

46. You click "Add to Cart" → React dispatches an Action (in Redux/Zustand state management)
47. The Cart Service (microservice) receives a POST request with product ID + quantity
48. Cart data is stored in DynamoDB (persistent) AND Redis (for fast reads)
49. If you're not logged in, the cart is stored in a Cookie + Redis using a session ID
50. When you log in later, the anonymous cart merges with your account's cart
51. The cart count in the navbar instantly updates (Optimistic update — UI updates before server confirms)
52. Cart is available across all devices — phone, tablet, laptop, Fire TV
53. The Price Service checks if the price changed since you added it

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 9: CHECKOUT & PAYMENT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

54. You click "Proceed to Checkout" — this is a multi-step flow handled by the Order Service
55. Step 1: Address Service — shows saved addresses, allows new one
56. Step 2: Shipping Service — calculates delivery dates (SLA)
57. Step 3: Payment Service — handles credit cards via Stripe/visa APIs (PCI-DSS compliant)
58. Step 4: Review Service — shows order summary, final price with tax
59. Step 5: Place Order button → starts a Transaction (all-or-nothing):
    a) Deduct inventory (Inventory Service — DynamoDB with conditional updates)
    b) Charge payment (Payment Service — third-party API call)
    c) Create order record (Order Service — Aurora/MySQL)
    d) Send confirmation email (SES — Simple Email Service)
    e) Add to fulfillment queue (SQS — Simple Queue Service)
60. If any step fails → entire transaction ROLLS BACK (no partial orders)
61. The confirmation page is SSR'd instantly — shows order ID, estimated delivery date
62. Behind the scenes, a WebSocket connection (or SSE) updates order status in real-time
63. The fulfillment queue (SQS) sends a message to the nearest warehouse robot

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 10: MESSAGING & QUEUES (HOW SERVICES TALK TO EACH OTHER)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

64. Services don't always talk directly — they use message queues for reliability
65. Amazon uses SQS (Simple Queue Service) and Kafka (MSK — Managed Streaming for Kafka)
66. When an order is placed, a message goes to a Queue:
    - Warehouse worker picks it up (Worker — a service that processes queue messages)
    - If the worker crashes, the message goes to a Dead Letter Queue for manual inspection
    - If the worker succeeds, the message is deleted from the queue
67. Kafka is used for real-time event streaming:
    - Every page view, click, search, add-to-cart is an event → Kafka
    - These events feed ML models (recommendations, fraud detection)
    - These events feed real-time analytics dashboards
68. This is Pub/Sub (Publish/Subscribe) — one service publishes events, many services subscribe

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 11: RECOMMENDATIONS & AI/ML (THE BRAINS)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

69. Amazon's recommendation engine drives 35% of all sales — it's their most important system
70. It uses collaborative filtering + deep learning models trained on SageMaker (AWS ML service)
71. Data sources for ML:
    - Your purchase history (DynamoDB)
    - Your browsing history (Kafka event stream)
    - Items in your cart (Redis + DynamoDB)
    - Items people like you bought ("Customers who bought this also bought")
    - Items you searched for
    - Time of day, day of week, season
    - Your location, device type
72. Models are trained on GPU clusters and deployed as APIs (SageMaker endpoints)
73. Predictions are pre-computed daily for popular items and stored in Redis (fast access)
74. Real-time predictions are computed on-the-fly for your specific request
75. Fraud detection models run on every order — flags suspicious activity (different shipping
    and billing address, multiple orders to same address, unusual purchase patterns)
76. Dynamic pricing models adjust prices based on demand, competitor prices, inventory levels
77. Inventory forecasting predicts how many units to stock at each warehouse

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 12: INFRASTRUCTURE & DEPLOYMENT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

78. Every microservice runs in Docker containers
79. Containers are orchestrated by EKS (Amazon's Kubernetes)
80. Each microservice has at least 3 replicas (redundancy)
81. During peak (Black Friday), HPA (Horizontal Pod Autoscaler) automatically spins up 10x more pods
82. Each pod has resource limits (CPU, RAM) defined — no single service can consume everything
83. New code is deployed multiple times per day via CI/CD pipeline (CodePipeline + CodeDeploy):
    - Developer commits code to Git → GitHub triggers the pipeline
    - Code is built, tested (unit tests, integration tests)
    - Docker image is built and pushed to ECR (Elastic Container Registry)
    - Canary deployment: 5% of traffic goes to new version first
    - If error rate increases → auto-rollback
    - If healthy → gradually increase to 100% (rolling update — one pod at a time)
84. Infrastructure is defined as code using Terraform — entire AWS setup is version-controlled
85. Configuration (feature flags, database URLs) is stored in AppConfig / Parameter Store
86. Secrets (API keys, database passwords) are stored in Secrets Manager with automatic rotation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 13: OBSERVABILITY (KNOWING WHAT'S HAPPENING)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

87. Every request is traced end-to-end using OpenTelemetry + AWS X-Ray (Distributed tracing)
88. You can see a request travel: Browser → CloudFront → ELB → Product Service → DynamoDB → Redis
89. Metrics (CPU, memory, request latency, error rates) are collected by CloudWatch + Prometheus
90. Dashboards are visualized in Grafana — real-time graphs of every system
91. Logs from all 10,000+ microservices stream to CloudWatch Logs / OpenSearch / ELK Stack
92. If something breaks, engineers search logs in Kibana / OpenSearch Dashboards
93. Alerts are configured in CloudWatch Alarms / Alertmanager:
    - "Error rate > 1%" → sends alert to Slack + PagerDuty
    - "Latency > 500ms" → alerts on-call engineer
    - "Disk 90% full" → auto-scales storage
94. Chaos Engineering (with AWS Fault Injection Simulator) intentionally breaks things to test
    if the system survives. Netflix calls this "Chaos Monkey" — Amazon has similar tools.
95. Post-mortems are written after every major incident — root cause analysis, fixes applied

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 14: SCALE — HOW BIG IS THIS?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

96. Amazon operates over 300+ microservices (each a separate deployable application)
97. Thousands of database instances across 30+ AWS regions worldwide
98. Every day: 1.6+ billion web requests, 500+ million database queries, petabytes of data
99. Over 200 million products cataloged, 300 million+ active customers
100. Each product page needs data from 12+ microservices (Phase 3) — all fetched in under 200ms

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SUMMARY: ALL AMAZON TECHNOLOGIES IN ONE LIST
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CATEGORY             │ TECHNOLOGIES AMAZON USES
─────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────
Frontend             │ HTML, CSS, JavaScript, React (they invented it), TypeScript, JSX
Rendering            │ SSR (Server-Side Rendering), Hydration, CSR (Client-Side Rendering), Lazy loading
Performance          │ Code splitting, Tree shaking, Minification, Bundling, WebP images, Lazy loading images, CDN
State Management     │ Redux, Flux architecture, Context API (React)
Styling              │ CSS-in-JS, Media queries, Responsive design, Flexbox, Grid, Mobile-first
Accessibility        │ ARIA, Screen reader support, ALT text, High contrast ratio
Search               │ Elasticsearch / OpenSearch, Full-text search, Fuzzy search, Auto-complete, Faceting, Ranking
APIs                 │ REST, gRPC, GraphQL, API Gateway, WebSocket, SSE, Webhook
Backend Languages    │ Java (primary), Node.js, Python, C++, Go
Backend Frameworks   │ Spring (Java), Express (Node.js), internal frameworks
Authentication       │ JWT, OAuth 2.0 (Login with Google/Facebook/Apple), Session cookies, MFA (Multi-Factor Auth)
Databases            │ DynamoDB (NoSQL), Aurora/MySQL (RDS - Relational), ElastiCache/Redis (Cache),
                     │ OpenSearch/Elasticsearch (Search), S3 (Object storage), Timestream (Time-series),
                     │ QLDB (Ledger/immutable), Redshift (Data warehouse/data analytics)
Caching              │ CloudFront (CDN), ElastiCache (Redis/Memcached), Browser cache, ETags
Messaging & Queues   │ SQS (Simple Queue Service), Kafka (MSK), SNS (Simple Notification Service - Pub/Sub)
Containerization     │ Docker, EKS (Kubernetes), ECS (Amazon's container service), Fargate (Serverless containers)
Infrastructure as Code│ Terraform, CloudFormation (AWS-native)
CI/CD                │ CodePipeline, CodeBuild, CodeDeploy, GitHub Actions, Jenkins, Canary deployments, Rolling updates
Monitoring           │ CloudWatch, Prometheus, Grafana, OpenTelemetry, X-Ray (Distributed tracing), Sentry (Error tracking)
Logging              │ CloudWatch Logs, OpenSearch/Kibana (ELK Stack), Loki
Alerting             │ CloudWatch Alarms, Alertmanager, PagerDuty, Slack
Networking           │ Route53 (DNS), CloudFront (CDN), ELB (Load balancer - Application/Network), VPC (Virtual Private Cloud),
                     │ WAF (Web Application Firewall), Shield (DDoS protection), Direct Connect (dedicated fiber)
Security             │ IAM (Identity & Access Management), KMS (Key Management Service), Secrets Manager,
                     │ Certificate Manager (SSL/TLS), GuardDuty (threat detection), Detective, Macie (data loss prevention)
Serverless           │ Lambda (functions), API Gateway, Step Functions (workflows), EventBridge (event bus)
Email & Notifications│ SES (Simple Email Service), SNS (Push notifications), Pinpoint (targeted campaigns)
Machine Learning     │ SageMaker (training + deployment), Personalize (recommendations), Forecast (demand prediction),
                     │ Fraud Detector, Rekognition (image analysis), Comprehend (NLP/text analysis)
Video & Streaming    │ Kinesis (real-time video/streaming data), MediaConvert (video transcoding), IVS (live streaming)
Storage              │ S3 (files, images, backups), EBS (block storage for EC2), EFS (shared file system), Glacier (archive)
Database Replication │ Multi-AZ (across data centers), Read replicas, Global tables (cross-region), Point-in-time recovery
Data Warehouse       │ Redshift (petabyte-scale analytics), Athena (SQL on S3), Glue (ETL - Extract Transform Load)
CI Patterns          │ Feature flags, A/B testing, Canary releases, Blue-green deployment, Chaos engineering
Testing              │ Unit tests, Integration tests, Load testing, Chaos Monkey / Fault injection, A/B tests
Payment              │ Stripe, Visa/Mastercard APIs, Amazon Pay, PCI-DSS compliance (security standard for payments)
Mobile               │ React Native (iOS/Android), Native Android (Kotlin), Native iOS (Swift), Fire OS
Hardware             │ AWS data centers worldwide, Custom Nitro chips, Graviton (ARM processors), Inf1 (ML inference chips)
Engineering Culture  │ Post-mortems, On-call rotations, Code reviews, Two-pizza teams (small teams), Working backwards
                     │ from customer needs, Six-page memos (no PowerPoint), Bar raiser hiring process

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
THE BIG PICTURE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Your single click on "Buy Now" triggers all of this in under 2 seconds:

  Browser → DNS → HTTPS → CDN → Firewall → Load Balancer → API Gateway → Auth Service →
  Product Service (12 sub-calls with caching) → Cart Service → Order Service →
    Payment Service → Inventory Service → Shipping Service → Queue → Warehouse Robot →
    Confirmation (reverse path)

Along the way it touches: HTML/CSS/JS/React → Java/Node.js → gRPC → Redis → DynamoDB →
Aurora → Elasticsearch → S3 → Kafka → Lambda → SageMaker ML → Docker → Kubernetes →
Terraform → CloudWatch → PagerDuty

And it all happens in under 2 seconds while handling 50,000+ other customers doing the same thing.

Your simple Suplecost app uses exactly the same concepts — just at a much smaller scale.
React frontend → Node.js backend → MySQL database → Redis cache → Docker → VPS.
Same architecture. Fewer zeroes.

====================================================================================================
= SWIGGY — HOW THE BIGGEST FOOD DELIVERY APP IN INDIA ACTUALLY WORKS
====================================================================================================
This is a step-by-step walkthrough of what happens when you open Swiggy, browse restaurants,
order food, and get it delivered. Every bolded term is defined in the glossary above.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 1: YOU OPEN THE SWIGGY APP
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. You open the Swiggy app on your phone (or visit swiggy.com on your laptop)
2. The app (React Native for both iOS and Android) makes an HTTPS request to the API
3. DNS lookup via Route53 or Cloudflare DNS → resolves to Swiggy's nearest server
4. Request hits CloudFront (CDN) — static assets (logos, icons, JS bundles) are served from edge
5. Dynamic API request passes through AWS WAF (Firewall) — blocks bots, SQL injection, DDoS
6. Request hits the Load Balancer (ELB — Elastic Load Balancer)
7. Load Balancer forwards to the API Gateway — the single entry point for all Swiggy APIs

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 2: DETECTING YOUR LOCATION (THE FIRST THING SWIGGY DOES)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

8. Your phone sends GPS coordinates with the request
9. The Location Service (microservice) hits Geo-coder API → converts lat/lng to city + area name
10. Location data is cached in Redis with TTL (so Swiggy doesn't re-geocode on every request)
11. If GPS is off, Swiggy falls back to IP geolocation (less accurate)
12. Your location determines:
    - Which restaurants are available (within delivery range)
    - Which delivery partners (delivery executives) are nearby
    - Estimated delivery time (ETA)
    - Dynamic delivery fees based on distance
    - Whether your area is serviceable at all
13. The allowed delivery area is stored as GeoJSON polygons in DynamoDB
14. Restaurants outside a 7 km radius from your location are filtered out immediately
15. This entire location lookup happens in under 50ms

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 3: LOADING RESTAURANTS NEAR YOU
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

16. The Restaurant Feed Service receives your location + filters (veg/non-veg, cuisine, sort)
17. It first checks Redis — if restaurant list for your area was cached in the last 5 minutes → return
18. If not cached → queries DynamoDB (Restaurant Catalog table) for restaurants near your location
19. DynamoDB uses a Geo-index (geospatial index) — finds all restaurants within your delivery radius
20. Each restaurant has a record containing: name, cuisine types, rating, avg delivery time, image URLs
21. The results are enriched by calling other microservices in parallel:
    a) Rating Service (DynamoDB) → average rating, total ratings count
    b) Offer Service (DynamoDB) → current discounts, coupons, "Buy 1 Get 1" offers
    c) Availability Service (Redis) → is the restaurant currently accepting orders? (real-time)
    d) Distance Service → exact delivery distance from your location to each restaurant
    e) ETA Service → estimated delivery time for each restaurant
    f) Dynamic Pricing Service → surge pricing if it's raining or peak time
22. Results are sorted by relevance: recommended → rating → fastest delivery → lowest cost
23. Promoted/paid restaurants appear first (Ad Service — same as Amazon's sponsored products)
24. Paginated — first 20 restaurants load instantly, more load when you scroll
25. The paginated JSON response is sent back to your phone
26. React Native renders the restaurant cards with lazy loading images (Cloudinary for image optimization)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 4: YOU TAP ON A RESTAURANT → MENU PAGE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

27. You tap "Domino's Pizza" → app sends GET request to /restaurant/dominos-pizza
28. The Menu Service (microservice) gathers data:
    a) Restaurant details (DynamoDB) — name, address, timings, photos
    b) Menu items (DynamoDB) — item name, description, price, images, category
    c) Customizations Service → available toppings, crust options, size variants
    d) Availability Service → which items are in stock right now (real-time inventory sync from restaurant POS)
    e) Review Service (DynamoDB + Elasticsearch) → user reviews + photos of food
29. Menu items are grouped into categories: "Pizzas", "Sides", "Beverages", "Desserts"
30. Each item has variants — size (Regular/Medium/Large) and crust (Thin Crust/Cheese Burst)
31. Each variant has a different price + different stock count
32. The entire menu is cached in Redis with TTL (2 minutes — menus update rarely)
33. Prices may show "Dynamically priced" — surge pricing based on demand (peak lunch hours)
34. Images are served via Cloudinary CDN in WebP format, responsive sizes for your screen
35. The response is JSON → React Native renders the menu page with categories, images, prices

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 5: YOU ADD ITEMS TO CART
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

36. You tap "ADD" on a Margherita Pizza (Medium, Cheese Burst) + Garlic Bread + Pepsi
37. Cart Service receives POST request with items, quantity, customizations
38. Cart data is stored in Redis (fast, temporary) + DynamoDB (persistent, survives app restart)
39. Each add-to-cart triggers a real-time price calculation:
    - Base price × quantity
    - Customization charges (extra cheese ₹50)
    - Applicable taxes (GST — 5% on food)
    - Restaurant packaging charges
    - Delivery fee (distance-based)
    - Surge pricing multiplier (if active)
    - Platform fee (₹3-5 per order)
    - Discounts applied (coupon codes, bank offers)
40. Cart total is recalculated and displayed instantly (Optimistic update)
41. The cart badge on the bottom tab updates in real-time — count + total amount
42. If you're not logged in, cart is stored against a Session ID (anonymous cart)
43. When you log in, the anonymous cart merges with your account's existing cart
44. Cart is synced across devices — add on phone, see on laptop

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 6: PLACING THE ORDER
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

45. You tap "PLACE ORDER" — this is the most critical transaction in Swiggy's system
46. The Order Orchestrator Service starts a distributed Transaction across 8+ services:
    
    Step 1 — Validate Service: Check if restaurant is still accepting orders (real-time check)
    Step 2 — Inventory Hold Service: Reserve the food items (reduce available count so no double-order)
    Step 3 — Pricing Service: Final price calculation (re-verify — prices could have changed)
    Step 4 — Coupon Service: Validate and apply coupon code (check expiry, minimum order, usage limit)
    Step 5 — Payment Service: 
      a) If wallet balance sufficient → deduct from Swiggy Wallet (DynamoDB with conditional update)
      b) If COD (Cash on Delivery) → no payment now, order goes directly to kitchen
      c) If Card/UPI → redirect to payment gateway (Razorpay, PayU, BillDesk)
         → User enters UPI PIN / Card OTP
         → Payment gateway sends Webhook to Swiggy confirming success
    Step 6 — Address Service: Verify delivery address is still serviceable
    Step 7 — Notification Service (SNS/SES): Send SMS + push notification to user: "Order confirmed!"
    
47. If any step fails → entire Transaction ROLLS BACK:
    - Inventory hold released (items go back to available)
    - Wallet amount refunded (if deducted)
    - User sees error: "Order failed, please try again"
48. If all succeed → order is created:
    - Order record inserted in DynamoDB with status: "PLACED"
    - Order pushed to a Queue (SQS) for the restaurant's kitchen display

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 7: RESTAURANT RECEIVES THE ORDER
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

49. Swiggy provides restaurants with a "Swiggy Tablet" (Android tablet or their own device)
    or an app on the restaurant's phone
50. The order message arrives from SQS (Simple Queue Service) into the restaurant's dashboard
51. The restaurant sees: order items, customizations, customer instructions, delivery address, ETA
52. The restaurant has a timer — must accept within 120 seconds or order auto-cancels
53. When restaurant taps "ACCEPT" → status changes from "PLACED" to "ACCEPTED"
54. If restaurant rejects → order is Cancelled → user gets refund + notification
55. Restaurant starts cooking — taps "PREPARING" when they begin
56. The entire status flow is a State Machine (Step Functions on AWS):
    PLACED → ACCEPTED → PREPARING → PREPARED → PICKED UP → IN TRANSIT → DELIVERED
57. Each status change triggers a Kafka event → multiple services subscribe:
    - Notification Service → sends push to user: "Your order is being cooked!"
    - Tracking Service → updates live order tracking
    - Analytics Service → logs order lifecycle metrics
    - Billing Service → starts billing timer (restaurant commission calculation)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 8: ASSIGNING A DELIVERY PARTNER
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

58. As soon as the order is ACCEPTED, the Assignment Engine kicks in (ML model on SageMaker)
59. The Assignment Engine considers:
    - All active delivery partners within 1 km of the restaurant
    - Each partner's current status (available, on delivery, on break)
    - Each partner's past performance rating (faster partners get priority)
    - Each partner's distance to restaurant
    - Order readiness time (don't assign too early — partner would wait)
    - Current load (don't overload one partner with multiple orders)
    - Traffic conditions (real-time traffic data from Google Maps API)
60. The optimal partner is chosen — this is a Constrained Optimization problem solved by ML
61. The partner receives a push notification + in-app sound: "New order! Tap to accept"
62. Partner has 15 seconds to accept → if not, reassigned to next best partner
63. When partner accepts → order status: "DELIVERY PARTNER ASSIGNED"
64. The partner sees on their app: restaurant, customer location, distance, earnings for this trip

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 9: REAL-TIME TRACKING (THE MOST COMPLEX PART)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

65. The delivery partner's app sends GPS coordinates every 5 seconds to Swiggy's Tracking Service
66. These coordinates are ingested via Kinesis (real-time data streaming)
67. Data flows through Kafka → processed by the Live Tracking Service
68. The user's app polls the tracking endpoint every 3 seconds (Short polling via REST)
    OR uses WebSocket / SSE for real-time push updates (more modern approach)
69. The user sees on their screen:
    - The delivery partner's icon moving on a Google Map (React Native Maps)
    - ETA countdown: "Arriving in 12 minutes"
    - Partner's name, photo, vehicle number
    - A "Call Partner" button (phone number masked — Twilio for anonymized calling)
70. The ETA is recalculated continuously using:
    - Current GPS position → distance remaining
    - Real-time traffic data (TomTom/Google Maps API)
    - Historical delivery time for this area (ML prediction)
    - Elevator/lift availability (delivery to high-rise vs ground floor)
71. If the partner is stuck in traffic → ETA dynamically adjusts → user sees "Delayed by 5 mins"
72. Multi-order batching is visible: if the partner has 2 deliveries, you see "Delivering 1 order before yours"

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 10: DELIVERY & COMPLETION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

73. Partner reaches your location → taps "REACHED" on their app
74. User gets push notification: "Your delivery partner has arrived!"
75. Partner hands over food → user receives order
76. Partner taps "DELIVERED" → status moves to COMPLETED
77. The payment to the restaurant + partner is triggered:
    - If COD: partner collects cash
    - If prepaid: settlement runs in batch (nightly) — Swiggy collects, pays restaurant minus commission
78. User gets a rating prompt:
    - Rate the food (1-5 stars) → Review Service (DynamoDB + Elasticsearch)
    - Rate the delivery (1-5 stars) → Partner Rating Service
    - Optional text review + photo
79. The ratings affect:
    - Restaurant ranking in search results
    - Partner's future assignment priority (low-rated partners get fewer orders)
    - Partner's incentive/bonus eligibility
80. User gets order summary: items, final price, delivery time, savings

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 11: SWIGGY'S BACKEND INFRASTRUCTURE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

81. Swiggy runs primarily on AWS, with some services on Google Cloud Platform (GCP)
82. They operate over 200+ microservices (Java, Kotlin, Go, Node.js)
83. Each microservice runs in Docker containers → orchestrated by Kubernetes (EKS)
84. Infrastructure defined with Terraform — entire AWS setup is code
85. CI/CD pipeline: GitHub → Jenkins/CodePipeline → build → test → deploy via Spinnaker
86. Deployments use Canary deployment + Blue-green — 5% traffic → 50% → 100%
87. Auto-scaling policies:
    - Lunch time (12-2 PM) → 3x normal capacity
    - Dinner time (7-9 PM) → 2.5x normal capacity
    - Rainy days → 5x capacity (everyone orders in)
    - Cricket match nights → spike depending on match timing
    - Diwali / New Year → highest traffic of the year — 8-10x normal
88. HPA (Horizontal Pod Autoscaler) auto-spawns pods in Kubernetes during these peaks
89. They use Spot instances for cost savings — 60-90% cheaper than regular EC2

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 12: SWIGGY'S DATABASES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

90. Like Amazon, Swiggy uses multiple databases each for its purpose:

    DynamoDB (NoSQL) — Used for: restaurant catalog, menu items, user profiles, orders,
    cart data, delivery partner profiles. Reason: needs millions of reads/writes per second
    during peak hours, serverless auto-scaling.

    Aurora / RDS (MySQL/PostgreSQL) — Used for: financial records, restaurant payouts,
    commission calculations, tax records. Reason: ACID compliance, complex aggregation queries.

    ElastiCache (Redis) — Used for: session data, cart cache, restaurant feed cache,
    real-time availability flags, rate limiting, ETA cache. Reason: sub-millisecond reads.

    OpenSearch / Elasticsearch — Used for: restaurant search ("Pizza near me"), menu search,
    log analytics, support ticket search. Reason: full-text search with fuzzy matching.

    S3 — Used for: food images, restaurant logos, user-uploaded review photos,
    backups, audit logs, analytics exports.

    DynamoDB Streams + Kinesis — Used for: real-time event streaming, order status changes,
    location updates from delivery partners.

    Redshift — Used for: data analytics, business intelligence dashboards, revenue reports,
    partner performance analytics. Reason: petabyte-scale SQL queries on data warehouse.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 13: SWIGGY'S OBSERVABILITY & ON-CALL
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

91. Every request is traced with OpenTelemetry + AWS X-Ray (distributed tracing)
92. Metrics via CloudWatch + Prometheus → dashboards in Grafana
93. Logs shipped to ELK Stack (Elasticsearch + Logstash + Kibana) / Loki
94. Key alerts (PagerDuty + Slack):
    - "Order placement failure rate > 1%" → critical alert
    - "Payment gateway latency > 5 seconds" → kills alternative gateway
    - "Delivery partner assignment time > 30 seconds" → algorithm degradation
    - "Restaurant tablet offline > 5 minutes" → restaurant may be unreachable
    - "Live tracking data delay > 10 seconds" → GPS pipeline issue
    - "Average order delivery time > 60 minutes" → systemic issue
95. Post-mortem culture: every major incident has a root cause analysis document
96. Chaos Engineering: Swiggy runs GameDays — intentionally break services to test recovery

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 14: SWIGGY'S SPECIAL FEATURES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

97. Swiggy One (Subscription) — like Amazon Prime:
    - Free delivery on all orders (normally ₹20-50 per order)
    - Extra discounts on select restaurants
    - Priority customer support
    - Managed via Subscription Service (DynamoDB) + Billing Service (Aurora)
98. Dynamic Surge Pricing:
    - During rain, traffic, peak hours → delivery fee increases
    - ML model predicts demand × supply of delivery partners
    - Surge multiplier shown transparently: "Delivery fee: ₹60 (1.5x surge)"
99. Restaurant Commission (Swiggy's revenue):
    - Swiggy takes 18-25% of every order as commission
    - Calculated by the Billing Service
    - Restaurants are paid weekly via automated bank transfers (Razorpay Payouts API)
100. Instamart / Swiggy Minis (Quick commerce — 10-30 min grocery delivery):
     - Same infrastructure + additional Inventory Management System
     - Dark stores (micro-warehouses in residential areas)
     - Real-time inventory sync via WebSocket
101. Dineout (Restaurant table booking):
     - Integration with restaurant POS systems
     - Real-time table availability
     - Payment held as deposit for no-shows

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 15: SCALE — SWIGGY BY THE NUMBERS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

102. 200,000+ restaurants across 500+ cities in India
103. 200,000+ delivery partners active daily
104. 2.5+ million orders per day (peak)
105. 500+ microservices running across multiple AWS regions
106. Over 10,000+ requests per second during peak lunch/dinner hours
107. Average order delivery time: 30-35 minutes (from tap to doorstep)
108. Over 50 million+ app downloads
109. Real-time GPS tracking for every active order (200,000+ partners sending location every 5 seconds)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SUMMARY: ALL SWIGGY TECHNOLOGIES IN ONE LIST
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CATEGORY             │ TECHNOLOGIES SWIGGY USES
─────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────
Frontend (App)       │ React Native (iOS + Android), JavaScript, TypeScript, React
Frontend (Web)       │ Next.js (swiggy.com), React, SSR, CSR, HTML, CSS
Maps & Location      │ Google Maps API, TomTom Traffic, GeoJSON, Geocoding, Kinesis (GPS stream)
Rendering            │ SSR, Hydration, Lazy loading, Code splitting, WebP, Responsive images
Search               │ Elasticsearch / OpenSearch, Full-text search, Fuzzy search, Auto-complete
APIs                 │ REST, GraphQL (some teams), WebSocket (live tracking), SSE (Server-Sent Events)
                     │ gRPC (inter-service), API Gateway
Backend Languages    │ Java (primary), Kotlin, Go, Node.js, Python (ML)
Backend Frameworks   │ Spring Boot (Java), Express (Node.js), Django (Python)
Authentication       │ JWT, OAuth (Google/Facebook login), OTP (SMS login), Session management
Databases            │ DynamoDB (NoSQL — catalog, orders, users, partners)
                     │ Aurora/RDS (MySQL — billing, settlements, financials)
                     │ ElastiCache/Redis (Cache — sessions, cart, feed, rates)
                     │ OpenSearch/Elasticsearch (Search — restaurants, logs)
                     │ S3 (Object storage — images, backups, logs)
                     │ Redshift (Data warehouse — analytics, BI)
                     │ DynamoDB Streams (Real-time events — order status changes)++
Caching              │ CloudFront (CDN), ElastiCache (Redis), Browser cache, ETags
Messaging & Queues   │ SQS (Order queue → restaurant tablet), SNS (Push notifications),
                     │ Kafka/MSK (Event streaming — order lifecycle, GPS data, analytics events)
Real-time            │ WebSocket (Live tracking), SSE, Kinesis (GPS stream), Polling (fallback)
Payments             │ Razorpay (primary), PayU, BillDesk, PhonePe, Google Pay, UPI,
                     │ Swiggy Wallet, Cash on Delivery, Stripe (international)
Containerization     │ Docker, EKS (Kubernetes), ECS (some legacy services)
CI/CD                │ GitHub, Jenkins, Spinnaker, CodePipeline, CodeBuild, CodeDeploy,
                     │ Canary deployments, Blue-green deployments, Rolling updates
Infrastructure as Code│ Terraform, CloudFormation (some legacy)
Monitoring           │ CloudWatch, Prometheus, Grafana, OpenTelemetry, X-Ray (distributed tracing)
Logging              │ CloudWatch Logs, ELK Stack (Elasticsearch + Logstash + Kibana), Loki
Alerting             │ CloudWatch Alarms, Alertmanager, PagerDuty, Slack
Networking           │ Route53 (DNS), CloudFront (CDN), ELB (Load balancer), AWS WAF (Firewall),
                     │ VPC, Shield (DDoS protection), Direct Connect
Security             │ IAM, KMS (Encryption), Secrets Manager, Certificate Manager (SSL/TLS),
                     │ GuardDuty, WAF (SQL injection, XSS protection)
Serverless           │ Lambda (background tasks — notifications, image resizing),
                     │ Step Functions (Order state machine — PLACED → ACCEPTED → DELIVERED),
                     │ EventBridge (Event bus), API Gateway
Machine Learning     │ SageMaker (Assignment engine — partner selection),
                     │ Forecast (Demand prediction — how many partners needed at 8 PM Friday),
                     │ Personalize (Restaurant recommendations),
                     │ Fraud Detector (Fake orders, coupon abuse)
Storage              │ S3 (Images, backups), EBS (block storage), EFS (shared file system)
Analytics & BI       │ Redshift (Petabyte SQL analytics), Athena (SQL on S3), QuickSight (Dashboards),
                     │ Amplitude (Product analytics), Mixpanel (User behavior)
Growth & Engagement │ Push notifications (SNS + Firebase Cloud Messaging),
                     │ Email (SES), In-app messages, SMS (SNS),
                     │ Deep linking (open app directly to a restaurant page)
Testing & QA        │ Unit tests, Integration tests, E2E tests (Cypress/Detox),
                     │ Load testing (k6/Artillery), Chaos Engineering (GameDays),
                     │ A/B testing (in-house experimentation platform)
Mobile Infrastructure│ Firebase (Crashlytics — crash reporting, Remote Config — feature flags,
                     │ Cloud Messaging — push, Dynamic Links)
Customer Support    │ Zendesk (ticketing), Intercom (in-app chat), Twilio (masked calling)
Developer Tools     │ GitHub, Jira (project management), Confluence (docs), Slack (communication),
                     │ PagerDuty (on-call), DataDog (some teams), Sentry (error tracking)
Hardware            │ AWS EC2 (compute), AWS EKS (Kubernetes nodes), Graviton (ARM instances for cost saving),
                     │ Spot instances (60-90% cheaper for batch jobs)
Compliance          │ PCI-DSS (payment security), SOC2 (data security), GDPR (user data privacy),
                     │ India's IT Act, FSSAI (food safety compliance for restaurants)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
THE BIG PICTURE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Your single tap on "Place Order" triggers all of this:

  GPS → DNS → CDN → Firewall → Load Balancer → API Gateway → Auth Service →
  Location Service → Restaurant Feed → Menu Service → Cart Service →
    Order Orchestrator (8+ services) → Payment Gateway (Webhook) →
    SQS → Restaurant Tablet → Assignment Engine (ML) → Delivery Partner →
    GPS → Kinesis → Kafka → Live Tracking → WebSocket → Your Phone →
    DELIVERED → Rating Prompt

Along the way it touches: React Native → Java/Go → gRPC → Redis → DynamoDB →
Aurora → Elasticsearch → Kafka → SQS → SNS → Lambda → SageMaker ML → Docker →
Kubernetes → Terraform → CloudWatch → PagerDuty → Razorpay → Google Maps

And it all happens in under 30 seconds for the order placement + under 35 minutes for delivery,
while handling 10,000+ other customers ordering food at the exact same moment in your city alone.

Just like Amazon, just like Suplecost — same fundamental architecture, different domain.