Forem: Sreekar Reddy

♿ Web Accessibility Explained Like You're 5

Sreekar Reddy — Wed, 06 May 2026 22:54:14 +0000

Making websites usable for everyone

Day 132 of 149

👉 Full deep-dive with code examples

The Curb Cut Analogy

Curb cuts (ramps in sidewalks) were designed for wheelchairs, but help everyone:

Parents with strollers
People with luggage
Delivery workers with carts
Cyclists

Web accessibility is the same!

Designing for disabilities improves the experience for everyone.

Why It Matters

Over 1 billion people have disabilities:

Visual → Blind, low vision, color blind
Hearing → Deaf, hard of hearing
Motor → Can't use mouse, limited movement
Cognitive → Dyslexia, attention issues

Without accessibility, your website locks them out.

How People Access the Web Differently

Screen readers → Read page aloud for blind users
Keyboard only → No mouse, just Tab and Enter
Voice control → Speak commands
Screen magnifiers → Zoom in for low vision

Your website needs to work with all of these!

Simple Accessibility Wins

Images:

Add alt text: "Golden retriever playing in park"
Screen readers can describe images to blind users

Colors:

Don't rely only on color (red for error)
Good contrast between text and background

Keyboard navigation:

Can users Tab through the page?
Are buttons and links focusable?

Forms:

Label every input field
Show clear error messages

Benefits Beyond Disabilities

Accessibility helps:

Elderly users with declining vision
Mobile users with small screens
Users in bright sunlight (need contrast!)
SEO (search engines read alt text too!)

In One Sentence

Web Accessibility means designing websites so everyone, including people with disabilities, can use them—and it makes sites better for everyone.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

🧩 Web Components Explained Like You're 5

Sreekar Reddy — Tue, 05 May 2026 22:57:27 +0000

Reusable custom HTML elements

Day 131 of 149

👉 Full deep-dive with code examples

The LEGO Brick Analogy

LEGO bricks are reusable building blocks:

Each brick works independently
Combine them to build anything
Same brick works in any LEGO set

Web Components are LEGO bricks for websites!

Create a component once, use it anywhere.

The Problem They Solve

Before Web Components:

Copying HTML, CSS, JS between projects
Styles from one component affecting others
Different frameworks couldn't share components
Hard to encapsulate functionality

What Web Components Give You

Custom Elements:

Define your own HTML tags
<user-card> instead of <div class="user-card">

Shadow DOM:

Component has its own isolated styles
No CSS leaking in or out

HTML Templates:

Reusable HTML structures
Only rendered when needed

A Simple Example

Create a custom element:

<my-greeting name="Alice"></my-greeting>

Renders as:

Hello, Alice! Welcome to our site.

Use it anywhere like a regular HTML tag!

Benefits

Encapsulation → Styles and logic stay inside
Reusability → Same component in any project
Framework agnostic → Works with React, Vue, or vanilla JS
Native browser support → No library needed

Common Uses

Design systems → Company-wide UI components
Widgets → Video players, date pickers
Micro frontends → Independent components from different teams

In One Sentence

Web Components let you create custom, reusable HTML elements with encapsulated styles and behavior that work in any web project.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

📱 Progressive Web Apps Explained Like You're 5

Sreekar Reddy — Mon, 04 May 2026 22:57:51 +0000

Websites that feel like apps

Day 130 of 149

👉 Full deep-dive with code examples

The Best of Both Worlds Analogy

You want pizza:

Restaurant: Great experience, but you have to go there
Delivery: Comes to you, but takes time each order
Home oven with frozen pizza: Available anytime, like having the restaurant at home!

PWAs are like having the restaurant experience at home!

All the benefits of apps, without the app store.

The Problem They Solve

Native apps are great but:

Need to download from app store
Take up phone storage
Require separate iOS and Android versions
Updates need re-downloading

Websites are accessible but:

Need internet to work
Can't send notifications
Not on home screen
Feel "less real" than apps

How PWAs Fix This

PWAs combine the best of both:

Install from browser → No app store needed
Work offline → Cached data and pages
Home screen icon → Feels like a real app
Push notifications → Keep users engaged
One codebase → Works on all devices

Key Features

Service Workers:

Run in the background
Cache files for offline use
Handle push notifications

Manifest file:

Tells browser it's installable
Sets icon, colors, name
Configures how it launches

HTTPS required:

Security is mandatory
Protects user data

Real Examples

Twitter Lite → PWA, 70% data reduction
Starbucks → Works offline for ordering
Pinterest → 40% more user engagement
Spotify Web Player → PWA for music

In One Sentence

Progressive Web Apps are websites that work like native apps—installable, fast, and work offline—without needing an app store.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

🖥️ SSR vs CSR Explained Like You're 5

Sreekar Reddy — Sun, 03 May 2026 22:44:40 +0000

Where your page gets rendered

Day 129 of 149

👉 Full deep-dive with code examples

The Restaurant Analogy

Two types of restaurants:

Full-service restaurant (SSR):

Kitchen prepares complete meal
Served ready to eat
You just enjoy it

Build-your-own taco bar (CSR):

You get ingredients
You assemble at your table
More interactive, but takes time

SSR vs CSR is about where the webpage gets built!

Server-Side Rendering (SSR)

The server builds the complete HTML page:

User visits → Server builds page → Sends complete HTML → User sees content immediately

Benefits:

Fast first load (content right away)
Great for SEO (search engines see full content)
Works without JavaScript

Downsides:

Every click might need a new page from server
Server does more work

Client-Side Rendering (CSR)

The browser builds the page with JavaScript:

User visits → Server sends empty shell → Browser runs JavaScript → Content appears

Benefits:

After first load, navigation is instant
Feels like an app, not a website
Server does less work

Downsides:

Blank page until JavaScript loads
Search engines may not see content
Needs JavaScript to work

When To Use Which

Choose SSR when:

SEO matters (blogs, e-commerce)
Fast first load is critical
Users might have slow devices

Choose CSR when:

Building app-like experiences (dashboards)
Lots of interactivity
Users stay and explore (not quick visits)

Modern approach:

Many sites use BOTH (hybrid)
SSR for first load, CSR for navigation

In One Sentence

SSR has the server build pages (fast first load, good SEO), while CSR has the browser build them (app-like experience after initial load).

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

📮 REST API Explained Like You're 5

Sreekar Reddy — Sat, 02 May 2026 22:44:59 +0000

Web services using HTTP verbs

Day 128 of 149

👉 Full deep-dive with code examples

The Library Analogy

A library with standard commands:

GET a book - Receive book
POST a book - Donate new book
PUT a book - Replace with updated version
DELETE a book - Remove from library

REST APIs use the same HTTP verbs to operate on resources.

HTTP Methods = CRUD

Method	Action	Example
GET	Read	`GET /users`
POST	Create	`POST /users`
PUT	Update	`PUT /users/1`
DELETE	Delete	`DELETE /users/1`

Real Example

// Get all users
const users = await fetch("/api/users");

// Create user
await fetch("/api/users", {
  method: "POST",
  body: JSON.stringify({ name: "Alice" }),
});

Best Practices

Use nouns, not verbs (/users not /getUsers)
Use plurals (/products not /product)
Return proper status codes (200, 201, 404, etc.)

In One Sentence

REST APIs use standard HTTP methods (GET, POST, PUT, DELETE) to interact with resources identified by URLs.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

🚛 Database Migrations Explained Like You're 5

Sreekar Reddy — Fri, 01 May 2026 22:52:51 +0000

Version control for database schema

Day 127 of 149

👉 Full deep-dive with code examples

The Recipe Card Analogy

Your grandma's recipe evolves:

Version 1: Original recipe
Version 2: Add a pinch of salt
Version 3: Use brown sugar instead of white
Each change is recorded and reversible

Database migrations track changes to your database structure!

Why Migrations Matter

Without migrations:

"Did we add that column?"
"What does the database look like in production?"
"How do I set up a new developer's database?"

Everyone's database might be different!

How They Work

Each migration is a file:

Migration 1: Create users table
Migration 2: Add email column to users
Migration 3: Create orders table
Migration 4: Add index on email

Run in order, your database evolves consistently.

Key Features

Forward (up):

Apply changes: add column, create table

Backward (down):

Undo changes: remove column, drop table

Version tracking:

Database knows which migrations have run
Only applies new ones

Benefits

Consistent → All databases match
Repeatable → New developer runs migrations, instant setup
Reversible → Mistake? Roll back
Auditable → History of all changes

The Workflow

Write migration (add column, change type)
Test locally
Commit to version control
Deploy runs migrations automatically
Production updated safely!

In One Sentence

Database Migrations are versioned scripts that track and apply changes to your database structure, so every environment stays in sync.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

📦 Stored Procedures Explained Like You're 5

Sreekar Reddy — Thu, 30 Apr 2026 22:55:41 +0000

Saved SQL scripts in the database

Day 126 of 149

👉 Full deep-dive with code examples

The Restaurant Kitchen Analogy

Ordering at a restaurant:

You don't tell the chef each step: "Boil water, add pasta, cook 10 min..."
You just say: "Spaghetti Carbonara, please"
The chef already knows the recipe

Stored procedures are recipes stored in the database!

You call them by name instead of writing the steps each time.

The Problem They Solve

Without stored procedures:

Every app sends complex SQL to the database
Same logic repeated in multiple places
If logic changes, update everywhere
More network traffic

How They Work

You write the procedure once:

Create procedure "GetCustomerOrders":
  1. Find customer by ID
  2. Get all their orders
  3. Sort by date
  4. Return results

Then call it:

Execute GetCustomerOrders(customer_id: 123)

The database runs all steps internally!

Benefits

Faster → Less data sent over network
Reusable → Call same procedure from anywhere
Access-controlled → Users can run procedure without direct table access
Maintainable → Change logic in one place

When To Use Them

Good for:

Complex operations with multiple steps
Business logic that should live in database
Performance-critical queries
Enforcing consistent data rules

Maybe avoid when:

Logic changes frequently
You want portable code across databases
Simple queries that don't need reuse

In One Sentence

Stored Procedures are pre-written programs saved in the database that you can run by name, like calling a recipe instead of writing all the steps.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

📏 Database Normalization Explained Like You're 5

Sreekar Reddy — Wed, 29 Apr 2026 22:58:33 +0000

Organizing data to reduce redundancy

Day 125 of 149

👉 Full deep-dive with code examples

The Address Book Analogy

Bad address book:

"John Smith, 123 Main St, Sydney NSW 2000"
"John Smith, 123 Main St, Sydney NSW 2000" (repeated!)
What if John moves? Update every entry!

Good address book:

Contact list: John Smith → Contact ID: 1
Address list: Contact ID: 1 → 123 Main St, Sydney
One place to update!

Normalization organizes data to avoid repetition!

The Problems It Solves

Data repetition:

Same information in many places
Wastes storage space
Easy to have mismatches

Update anomalies:

Change one place, forget another
Data becomes inconsistent

Deletion anomalies:

Delete one thing, accidentally lose other info

How It Works

Split data into related tables:

Before (unnormalized):

| OrderID | Customer | CustomerEmail  | Product |
| 1       | Alice    | alice@mail.com | Laptop  |
| 2       | Alice    | alice@mail.com | Mouse   |

Alice's email repeated!

After (normalized):

Customers: | CustomerID | Name  | Email           |
           | 1          | Alice | alice@mail.com  |

Orders:    | OrderID | CustomerID | Product |
| 1 | 1 | Laptop |
| 2 | 1 | Mouse  |

Email stored once, linked by ID.

Benefits

No redundancy → Data stored once
Consistency → One source of truth
Easier updates → Change in one place
Less storage → No duplicate data

The Trade-off

More tables = more joins (slower queries sometimes).

Balance: Normalize for correctness, denormalize for performance when needed.

In One Sentence

Database Normalization organizes data into tables that minimize repetition, ensuring data is stored once and stays consistent.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

📐 CAP Theorem Explained Like You're 5

Sreekar Reddy — Tue, 28 Apr 2026 22:58:02 +0000

Pick two: consistency, availability, partition tolerance

Day 124 of 149

👉 Full deep-dive with code examples

The Three Wishes Analogy

A genie says: "Pick any TWO wishes, but not all three"

Wish 1: Fastest car
Wish 2: Cheapest car
Wish 3: Most reliable car

You can have fast + cheap (less reliable), or cheap + reliable (not fast).

CAP is like this—but the real trade-off shows up when the network is split (a partition).

The Three Properties

C - Consistency:

Reads behave as if there were a single up-to-date copy (strong consistency)
In practice, “consistency” has levels; CAP discussions usually mean a very strong form

A - Availability:

Every request gets a response from a non-failing node
That response might be an error (the key point is: the system doesn’t stop responding)

P - Partition Tolerance:

The system keeps operating even if messages between servers are dropped/delayed (a network partition)

Why You Can't Have All Three

Imagine two servers that should stay in sync:

Server A ←─ network break ─→ Server B

Network breaks. A user writes to Server A.

Option 1: Stay Consistent

Don't let Server B respond until synced
But Server B becomes unavailable!

Option 2: Stay Available

Both servers respond with what they have
But data is now inconsistent!

During a partition, you must choose what to prioritize.

Real-World Choices

CP (Consistency + Partition Tolerance):

Bank transactions
Might be briefly unavailable

AP (Availability + Partition Tolerance):

Social media feeds
Might show slightly stale data

CA (rarely used):

Only works when you assume no partitions (for example: a single-node system or a very reliable network)

In One Sentence

CAP Theorem says that when a network partition happens, a distributed system has to trade off between consistency and availability.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

⚗️ ACID Properties Explained Like You're 5

Sreekar Reddy — Mon, 27 Apr 2026 22:54:58 +0000

Guarantees for data reliability

Day 123 of 149

👉 Full deep-dive with code examples

The Bank Transfer Analogy

Transferring money from Account A to B:

Subtract the amount from A
Add the amount to B

What if the power goes out between steps?

A lost $100
B didn't get it
Money vanished!

ACID properties are the goals that help prevent this kind of disaster.

What ACID Stands For

A - Atomicity:

"All or nothing"

Either both steps happen, or neither
No partial transfers

C - Consistency:

"Rules are enforced"

Balance can't go negative
Constraints/invariants stay true (according to your schema and business rules)

I - Isolation:

"Transactions don't see each other's incomplete work"

Your transfer doesn't mess up someone else's
Like each transaction runs without being confused by half-finished changes (exact guarantees depend on the isolation level)

D - Durability:

"Once done, it stays done"

Power outage after? Data is still saved
Written to permanent storage

Why It Matters

Without ACID:

Money disappears or duplicates
Inventory goes negative
Orders get lost
Users see incorrect data

With ACID:

Transactions are more reliable
Data stays consistent
You can trust your database

A Quick Example

Transfer money from A to B:

Start transaction
  Check: A has enough money ✓
  Subtract amount from A
  Add amount to B
Commit transaction (all done, saved!)

If anything fails → Rollback (nothing changes)

In One Sentence

ACID properties describe the guarantees a database tries to provide for transactions so changes are applied safely (or rolled back) even when things fail.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

📋 Database Replication Explained Like You're 5

Sreekar Reddy — Sun, 26 Apr 2026 22:41:08 +0000

Copying data to multiple servers

Day 122 of 149

👉 Full deep-dive with code examples

The Backup Copy Analogy

Important documents:

One copy at home
One copy at the bank
One copy at your lawyer's

If your house burns down, you still have copies!

Database Replication keeps copies of your database in multiple places!

Why Replicate?

Safety:

If one server fails, another replica may still have the data (and can take over, depending on your setup)
Can reduce data-loss risk, but replication is not a full backup strategy by itself

Speed:

Users far away can read from a nearby replica
Can reduce read latency for globally distributed users

Availability:

One server down → Others handle requests
Less downtime for users (depending on failover and client behavior)

Types of Replication

Primary-Replica:

Primary (writes) ──→ Replica 1 (reads)
                └──→ Replica 2 (reads)

One leader accepts writes
Replicas get copies, handle reads

Multi-Primary:

Multiple servers accept writes
More complex, handles conflicts

The Trade-offs

Consistency:

Replicas might be slightly behind
User writes, then reads from replica = might see old data

Complexity:

Managing multiple servers
Handling conflicts if two writes happen

Common Uses

Global apps → Replicas in each region
High-traffic sites → Spread read load
Disaster recovery → Backup in different location

In One Sentence

Database Replication copies your data to multiple servers for safety, speed, and availability when one server isn't enough.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

🍕 Database Sharding Explained Like You're 5

Sreekar Reddy — Sat, 25 Apr 2026 22:39:12 +0000

Splitting data across servers

Day 121 of 149

👉 Full deep-dive with code examples

The Library Card Catalog Analogy

One huge card catalog is hard to use:

Long lines at one catalog
If it breaks, no one can find books

Split by letters:

A-F catalog in room 1
G-M catalog in room 2
N-Z catalog in room 3

Search is faster, and if one catalog goes down, you can still use the others (but you lose access to that section until it comes back).

Sharding splits your database into pieces across servers!

Why Shard?

One server has limits:

Storage → Runs out of disk space
Speed → Too many queries to handle
Memory → Can't fit all data in RAM

Sharding spreads the load across multiple servers.

How It Works

Split data by some key:

Users A-H → Server 1
Users I-P → Server 2
Users Q-Z → Server 3

Each piece is a "shard." Each shard handles its portion.

Sharding Strategies

By key range:

Users 1-1000 → Shard 1
Users 1001-2000 → Shard 2

By hash:

hash(user_id) % 3 → determines shard
Often spreads data more evenly

By geography:

US users → US shard
EU users → EU shard

The Trade-offs

Complexity:

Queries across shards are hard
Need to route requests correctly

Availability:

Sharding doesn't automatically make you highly available
If a shard goes down, data on that shard is unavailable unless you also use replication

Joins:

Can't easily join data across shards
Might need to restructure queries

Rebalancing:

Adding new shard? Need to move data

In One Sentence

Database Sharding splits your data across multiple servers so each handles a smaller piece, allowing your database to scale beyond one machine's limits.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.