DEV Community: Ateeb Hussain

Why is your Database Index actually fast?

Ateeb Hussain — Mon, 20 Apr 2026 06:55:11 +0000

We’ve spent all week talking about Redis Hashes, Bloom Filters, and Tries.

But let’s be real: 90% of the time, you’re just hitting a PostgreSQL Index.

Ever wondered what’s actually happening when you add @unique or CREATE INDEX? It’s not just a "magic list." It’s almost always a B+ Tree.

What is a B+ Tree?

Think of it as a perfectly balanced, multi-level library.

In a normal Binary Tree, you only have two branches. In a B+ Tree, each "node" can have hundreds of branches. This means even if you have BILLIONS of records, the database only needs to look at 3 or 4 levels to find your specific data.

Why B+ Trees are the GOAT:

Range Queries: Unlike Redis Hashes (which are bad at "give me users with ID 10 to 50"), B+ Trees keep all their data at the "leaves" in a linked list. You can slide across them instantly.
Disk Friendly: Databases don't live in RAM (usually). B+ Trees are designed to be read from your SSD in "blocks," making them incredibly efficient for physical storage.
Balanced Performance: Whether you’re searching for the 1st record or the 1,000,000th, the time taken ($O(\log n)$) is virtually the same.

The Reality Check:

Redis Hash: Instant, but expensive (RAM).
B+ Tree (SQL Index): Very fast, cheaper (Disk), and handles ranges like a pro.

This is why I keep saying: For my 10k user projects, a well-indexed Postgres table is more than enough. You don't need to over-engineer until you actually have the traffic to justify it.

Series Wrap-up:
We’ve covered:

Redis Hashes (Storage efficiency)
Bloom Filters (The Bouncer)
Trie Structures (Prefix/Search)
B+ Trees (The Foundation)

The most important skill isn't knowing how to build these—it's knowing WHICH one to pick for your specific problem.

That’s a wrap on this System Design series!

Which of these four surprised you the most? Or is there another structure I missed? Let’s nerd out in the comments!

How do "Suggested Usernames" actually work?

Ateeb Hussain — Sun, 19 Apr 2026 11:47:00 +0000

We’ve talked about Redis Hashes for storage and Bloom Filters for the "Bouncer" at the door.

But what happens when ateebHussain is taken and you need to suggest:

ateebHussain_1
ateebHussain_pro
ateeb_h

If you try to do this with LIKE %ateeb% in a SQL database with 10 million rows... RIP your latency.

Enter: The Trie Structure (Prefix Tree)

A Trie is a specialized tree used to store associative arrays. Instead of storing whole strings, it stores characters as nodes.

Imagine it like a path:
A -> T -> E -> E -> B

Why this is a Game Changer:

Autocomplete in $O(L)$ Time: Where $L$ is the length of the word. It doesn't matter if your DB has 1 billion names; finding "ateeb" takes the same amount of time.
Prefix Matching: It’s built for "starts with" queries. You can find every username starting with "ateeb" in milliseconds.
Memory Sharing: Usernames like ateeb1, ateeb2, and ateeb_dev all share the same "ateeb" prefix nodes. It’s incredibly efficient for overlapping data.

Where to use it?

Search Bars: That "Search as you type" feature? Probably a Trie.
Username Suggestions: Instantly finding the next available variation.
IP Routing: High-speed networking uses this to route your data packets!

Building a Trie from scratch in production can be overkill for a small LMS or a simple store. But understanding how it works separates the "I just use frameworks" devs from the "I design systems" engineers.

If you’re using Next.js, you can actually implement a simple version of this in an Edge Function for insane performance.

Next post: B+ Trees. (The reason your PostgreSQL indexes actually work).

Have you ever tried implementing a Trie, or do you just let your frontend handle the filtering? Let’s talk architecture!

How bloom filters work, irl

Ateeb Hussain — Thu, 16 Apr 2026 16:35:33 +0000

A single SELECT for every "Username Taken" check?
Seriously??

Imagine you're building a SaaS and 10,000 bots try to sign up with random usernames in one minute.

Are you really gonna let your Postgres/MySQL handle 10,000 unnecessary hits just to say "Nope, doesn't exist"?
That’s how you kill your DB performance and blow your AWS budget on RDS IOPS.

Tech Giants don't even touch the database to check if a username is free. They use a Bloom Filter.

The "Bouncer" at the door

Think of a Bloom Filter as a high-speed bouncer. He doesn't have a list of names; he just has a row of 1,000 switches (bits).

When a user signs up, you run their name through a Hash Function.
It flips a few switches to ON.
When the next person checks a name, the bouncer just looks at the switches.

The Result?

If the switches are OFF: The username 100% DOES NOT exist. (Database: 0 hits. Speed: Lightning).
If the switches are ON: It might exist. Now you go check the DB.

Why this is a Flex:

Memory is Cheap: You can track 10 MILLION usernames in about 10MB of RAM. Try doing that with a SQL Index.
Zero Disk I/O: Your database stays chill while the Bloom Filter handles the noise.
Privacy: Even if someone hacks your Redis, they can't see the usernames. It’s just bits, baby.

Real Talk:
I know, I know... "Ateeb, I only have 500 users, I'll just use @unique in Prisma."
Fine. Use your sledgehammer for a nut.

But if you’re planning to scale to the moon, you need to stop being lazy with your architecture.

Next up: Trie Structures. (How to do those "Suggested Usernames" without making your server sweat).

Are you still "Select-ing" your way to a massive AWS bill, or are you actually optimizing? Fight me in the comments! 👇

Claude Code's architecture is pretty insane, isn't?

Ateeb Hussain — Wed, 15 Apr 2026 10:06:15 +0000

Let's talk about it...

Wow, now we can have filtered feeds. Discover/Following/Latest --- Nice

Ateeb Hussain — Tue, 14 Apr 2026 09:58:33 +0000

How Redis Hashes actually work?

Ateeb Hussain — Tue, 14 Apr 2026 09:56:03 +0000

If you’re just using Redis to SET and GET basic strings, you’re basically using a Ferrari to drive to the grocery store. You’re leaving money on the table.

The "Dictionary inside a Dictionary"

Stop thinking of Redis as just one giant list of keys. A Redis Hash is basically a container.

Instead of doing this:
user:username:ateeb -> "active"
user:email:ateeb -> "ateeb@example.com"

You do this:
user:ateeb -> { status: "active", email: "ateeb@example.com" }

Why do Tech Giants love this? (The nerdy bit)

It’s all about Memory Optimization. Redis is smart. If your Hash is small, it uses something called a ZipList. It literally squashes your data together to save space.

When that Hash gets huge, it automatically switches to a HashTable.

The result?

$O(1)$ Lookup: It doesn't matter if you have 100 users or 100 million. It finds that username instantly.
Cheaper Bills: You’re storing way more data in less RAM. Your AWS bill will thank you.

The Trade-offs (Because nothing is perfect)

The Good: Insanely fast. Perfect for "Hot Data" (users logging in constantly).
The Bad: You can’t set an expiry time (TTL) on just one field. It’s all or nothing for the whole hash.
The Ugly: If you need to search for "usernames starting with A," a Hash is NOT your friend. Use a Trie for that (covering that next!).

Real Talk:
I’m still rocking PostgreSQL with @unique for my 10k user projects. You don't need a sledgehammer to crack a nut. But when the nut is the size of a planet? You use Redis.

Next post: Bloom Filters. (How to tell if a username is taken WITHOUT even checking the DB).

What’s your go-to? Do you dump everything into one Hash, or do you prefer flat strings? Let's talk (keep it chill this time! 😅) 👇

Using Next.js with Redis

Ateeb Hussain — Mon, 13 Apr 2026 16:33:38 +0000

Is Redis (Upstash Redis) with Next.js a good matchup?

Another week of developing ECourses, an LMS SaaS (also opensource)

I implemented caching, or more precisely redis cache for the first time.

So... the previous was sending 10 database read queries while creating a single course.
What is that? Probably because I was fetching instructors to assign to a course and then for filtering too.

At first, I was using TanStack React Query for caching until it hit me that the cache is session based and temporary.

SSR or ISR are a bit headache because form is on client-side code.

So, it was time add some caching layers.
I already had React Query cache implemented, what need was redis to store recent data from database and next.js cache to store requested data for a short period of time – or until invalidated

The current caching flow looks like this:
User --> React Query --> NextJS Cache --> Redis Cache --> Database (PostgreSQL)

So, what are your thoughts about this flow...? I don't have a large group of users but I want to stay under the free stack, and hashtag#prisma postgres provides 10 concurrent connections with 100,000 operations per month.

P.S. What was your first caching flow you created?

Why let over var in JavaScript?

Ateeb Hussain — Sun, 12 Apr 2026 10:40:38 +0000

I didn't get it...

This is ECourses Progress Report 2, and you're witnessing AI taking over.

When I was having Claude writing three separate forms, routes and actions based on my previous code...

I stumbled upon something outrageous,
let retries = 0;

What is it? – I don't know, truly...

Basically, there are two ways to store data in JavaScript, in-fact everywhere

Constants and
Variables

While declaring constants is pretty straight forward,
variables can be declared in two ways,
using let and var

For years, var has dominated the JavaScript files until let stepped in.
Why?

var has a major risk. It is Function-based Scoped. (maybe I spelled it wrong)
BTW, the meaning is that once a variable is declared with var:

var retries = 0;

We can access the retries variable anywhere inside the function, this poses a threat in some cases.
While, using let for the same thing would restrict its scope to the parent code block i.e. curly braces { & }

There is more to it.

HOISTING !!!!!

The legendary NIGHTMARE for interviewee (Hope it is correct...)

So, var initializes the variable with null or undefined, while let stores it inside a Dead Zone the variable does not get initialized unless you do so...

The era of var came to an end,
And now, most files are dominated with let

Summary: ECourses is progressing butterly smooth...

How to lookup for usernames with a BILLION users?

Ateeb Hussain — Fri, 10 Apr 2026 05:30:14 +0000

It ain't this simple !!
A single damn SELECT query is not enough for your application !

Imagine that you're building a SaaS that requires username lookups every time a user signs-in.

Are you really gonna use
SELECT username FROM user WHERE username IS "ateebHussain";
Seriously??

That's not how tech giants do this, you are gonna rack up AWS bills just for one user when you have BILLIONS of records sitting in one DB TABLE.

Tech Giants, and other applications user a number of techniques/algorithms to handle username lookups efficiently with as much less time as possible.

These Involves:

Redis Hashmaps
Trie Structures
B+ Trees
Bloom Filters

Many a companies use a combination of theses for more efficient lookups and less false positives.

In the next post, I am gonna cover detailed implementation plan and PROS and CONS for each algorithm depending on your edge-case.

P.S. I'm still using username @unique with PostgreSQL for a 10k users System Design 😋

What was your first, "This ain't right" moment with usernames?

What Even Is The Purpose of Learning?

Ateeb Hussain — Wed, 08 Apr 2026 08:30:23 +0000

In this era of rapid AI hype, learning often feels… obsolete.

Especially when it comes to “learning how to code.”

“Learning to code has become optional” — but learning fundamentals and how things work under the hood is more important than ever.

Imagine you’re building a 100k MMR SaaS

(…of course, with zero bugs 😂)

and you don’t know which database to choose.

There are tons out there:

PostgreSQL – flexible queries, great for read‑heavy workloads
Cassandra – built for write‑heavy, no‑relational data
MongoDB – schema‑flexible, good for raw or vector‑like data
Redis – in‑memory, volatile, perfect for caching
Elasticsearch – search‑first, as the name suggests

But here’s the catch:

You don’t need all of them.

You don’t even need one “perfect” database.

It’s always about your use case.

How do you know which one to pick?

How do you choose the right architecture?

A Real‑World Mistake

While building an e‑commerce store, I decided to use all five of these.

AI was all in.

The idea sounded “scalable.”

The harsh reality?

At 10K users, a single PostgreSQL instance alone could’ve handled everything.

I learned it the hard way.

You can learn it the smart way.

Comment “Databases” and I’ll send you a short list of resources (articles, docs, and patterns) that helped me clean up that mess.

So, How Do You Decide on a Database?

Start with reads vs writes.
Ask: “Do I need relations or not?”
Ask: “Is this data transient, cached, or mission‑critical?”
Then, and only then, pick the tool.

The point isn’t to master every database.

It’s to understand enough fundamentals that you can stop over‑engineering and start shipping.

What’s your “I over‑engineered this and learned the hard way” story with databases or architecture? Drop it in the comments 👇

Project Structure of eCourses: How I Organized My LMS SaaS Codebase

Ateeb Hussain — Mon, 06 Apr 2026 07:00:00 +0000

In the previous post we looked at the overall architecture and tech stack of eCourses, but a lot of the “real” experience of shipping a product lives inside the project structure.
In this post, I’ll walk through how I’ve organized the code so far, the patterns that make the app easier to scale, and why this structure fits so well for a community‑first LMS SaaS.

What eCourses Is (Quick Recap)

eCourses is a Learning Management System SaaS built for small communities and independent educators.

Right now the codebase is:

Next.js 15 (App Router) + TypeScript + Prisma (PostgreSQL).
Authentication with Clerk.
Caching with Next.js fetch cache + Upstash Redis.
UI built with Tailwind CSS, shadcn/ui, and dnd‑kit.

All of this is glued together by a project structure that tries to stay predictable, scoped, and easy to grow.

Folder Layout at a Glance

Here’s the core layout (slightly trimmed for readability):

src/
├── app/
│   ├── [communitySlug]/
│   │   ├── admin/
│   │   │   ├── courses/
│   │   │   │   ├── page.tsx          # courses list with filters
│   │   │   │   ├── add/page.tsx      # create course
│   │   │   │   ├── edit/page.tsx     # edit course
│   │   │   │   └── manage/page.tsx   # manage modules & lessons
│   │   │   ├── analytics/
│   │   │   └── ...
│   │   ├── courses/                  # public course listing
│   │   ├── home/
│   │   └── sessions/
│   └── api/
│       ├── courses/
│       │   ├── route.ts             # GET, POST
│       │   └── [courseId]/route.ts  # GET, PATCH, DELETE
│       ├── modules/
│       │   ├── route.ts             # GET, POST
│       │   ├── reorder/route.ts     # PATCH
│       │   └── [moduleId]/route.ts  # DELETE
│       ├── lessons/
│       │   ├── route.ts             # POST
│       │   ├── reorder/route.ts     # PATCH
│       │   └── [lessonId]/route.ts  # DELETE
│       ├── members/
│       │   └── instructors/
│       │       ├── route.ts         # GET non‑student members
│       │       └── [userId]/route.ts
│       └── upload-auth/route.ts     # ImageKit auth
├── actions/
│   ├── courses.ts
│   ├── modules.ts
│   ├── lessons.ts
│   └── members.ts
├── components/
│   ├── courses/
│   ├── modules/
│   ├── lessons/
│   └── inputs/
├── hooks/
│   ├── use-course-form.ts
│   ├── use-course-filters.ts
│   ├── use-courses.ts
│   ├── use-instructor.ts
│   └── use-modules.ts
├── lib/
│   ├── api.ts           # verifyApiRequest, generateSlug, validateWithRegex
│   ├── cache.ts         # withCache, bustCache
│   ├── redis.ts         # Upstash Redis client
│   └── prisma.ts
└── types/
    ├── course.ts        # Prisma.CourseGetPayload types
    └── module.ts        # Prisma.ModuleGetPayload types

Why This Structure Works for an LMS

1. Community‑Scoped Routing

The key design choice is routing by communitySlug:

app/[communitySlug]/admin/courses/
app/[communitySlug]/courses/

This means:

Every route is scoped to a community, which maps naturally to the Community → Course → Module → Lesson model.
The same code can run multiple communities without needing separate deployments.

This is common in SaaS‑style LMS platforms, where you want to isolate data but reuse the same frontend logic.

2. Clean Separation: app / api / actions

I keep three layers for server‑side logic:

app/api/
- Pure internal API routes.
- Each ends with route.ts and follows REST‑ish patterns (e.g., GET /courses, GET /courses/[courseId]).
- All routes are protected via x-api-secret and verifyApiRequest().
actions/
- Server Actions that act as proxies to those API routes.
- They attach the secret server‑side so the API can be reused by both the frontend and a future mobile app.
lib/
- Shared utilities:
- api.ts → verifyApiRequest, generateSlug, validators.
- cache.ts → withCache, bustCache.
- prisma.ts → a single Prisma client instance.

This keeps the business logic out of the route handlers and makes it easier to test, refactor, and reuse.

3. Domain‑Driven Components

Inside components/, I group by domain:

components/
├── courses/
├── modules/
├── lessons/
└── inputs/

This means:

Anything that touches courses (cards, filters, forms) lives under courses/.
Video cards, drag‑and‑drop lists, accordions, and lesson forms live in lessons/ and modules/.
Shared form inputs live under inputs/ so they can be reused across multiple pages.

This pattern scales well as the LMS grows — adding new features like “assignments” or “quizzes” becomes a matter of adding a new domain folder instead of scattering logic everywhere.

4. Hooks: Collocating Logic with UI

The hooks/ folder is where I keep reusable logic that’s closely tied to the LMS model:

hooks/
├── use-course-form.ts          # manage course form state + validation
├── use-course-filters.ts       # sync URL query params with filter UI
├── use-courses.ts              # fetch and cache course lists
├── use-instructor.ts           # instructor‑related queries
└── use-modules.ts              # module list + reordering helpers

Keeping these hooks together:

Makes it easy to see what kinds of things the app can do just by scanning the folder.
Lets components stay thin and focused on UI instead of business logic.

This approach is common in modern LMS‑style apps, where you end up with many similar “list + filter + form” flows.

5. Types and the Data Model

The types/ folder currently holds:

course.ts → types derived from Prisma.CourseGetPayload.
module.ts → types for modules and their nested relationships.

I keep these thin, auto‑generated, and strongly aligned with the database schema:

Community
 └── Course (communityId, instructorId?)
       └── Module (courseId, index: Float)
             └── Lesson (moduleId, index: Float, type: VIDEO | SESSION)

This makes refactoring safer and keeps the TypeScript type system consistent with the underlying LMS model.

Things I Optimized for

When I was setting up this structure, I consciously optimized for:

Predictability
- New routes, components, and hooks follow a clear pattern so you can guess where to look.
Scalability
- Community‑scoped routing and modular components make it easy to add new features without breaking existing ones.
Separation of concerns
- API routes, server actions, UI components, and shared utilities each have their own place.
Developer experience
- TypeScript + Prisma + Zod + React Hook Form make the whole stack feel cohesive and type‑safe from top to bottom.

These are the same patterns I see in other production‑grade LMS‑style SaaS apps, where the complexity comes from the data model and workflows, not from a messy codebase.

How This Fits Into the Series

This post is the first deep dive into the codebase of eCourses. In future posts in this series, I’ll explore:

The data model and why Float index + soft delete works so well for drag‑and‑drop.
The caching strategy (three‑layer cache, tag‑based invalidation).
The admin‑panel UX patterns (optimistic UI, reordering, filters with URL state).
How server actions as API proxies will support a future mobile app.

If you found this structure helpful, drop a comment or a reaction — I’ll keep using this series to walk through real‑world decisions as eCourses grows. And if you’re building your own LMS or SaaS, feel free to borrow or adapt any of these patterns (and tweak them to fit your own style).

Building eCourses: A Community‑First LMS SaaS (and Why You Should Build in Public)

Ateeb Hussain — Sun, 05 Apr 2026 07:54:22 +0000

I’m building a Learning Management System SaaS called eCourses, designed specifically for small communities and independent educators who feel priced out or over‑engineered by existing platforms.

This post is the first in a series where I’ll walk through the architecture, decisions, and “lessons learned” from shipping an LMS from scratch — in public, open source, and on a tight budget.

Why I Built eCourses

Most LMS platforms are either:

Too expensive for solo creators and small communities.
Too complex for simple “course + modules + lessons + live sessions” workflows.
Too rigid to let instructors experiment with their own teaching style.

I wanted something that:

Feels native to communities (not just single instructors).
Scales technically and financially under $10/month at reasonable load.
Lets me experiment with API design, caching, and complex state in a real product context.

That’s how eCourses started — as a personal itch, and now as a real product and portfolio project.

What eCourses Is (Right Now)

At its core, eCourses is:

A community‑scoped LMS SaaS with communitySlug‑based routing.
An admin panel where instructors can:
- Create, edit, and soft‑delete courses (with image upload via ImageKit).
- Reorder modules and lessons with drag‑and‑drop (optimistic UI, two‑pass index transactions).
- Assign non‑student members as instructors.
A structure that prepares the ground for:
- Public course pages.
- Video upload and playback.
- Live sessions and recordings.
- Student progress tracking and analytics.

The live version is currently deployed at https://ecourses-sigma.vercel.app, and the whole stack is open source under the MIT license.

The Big Picture: Tech Stack

Right now the stack is optimized for type‑safe, fast iteration rather than maximal feature‑bloat:

Layer	Tech / Pattern
Framework	Next.js 15 (App Router + Turbopack)
Language	TypeScript
Auth	Clerk
Database	PostgreSQL
ORM	Prisma v7
Cache	Upstash Redis
File Storage	ImageKit
Frontend UI	Tailwind CSS v4 + shadcn/ui + dnd‑kit, nuqs, React Hook Form + Zod
State (HTTP)	TanStack Query v5 (React Query v4 in browser)

This gives me strong typing, rapid iteration, and a clear path to a mobile‑ready backend later.

If You Want to Follow Along

Right now eCourses is:

Live at: https://ecourses-sigma.vercel.app.
Open source under MIT.
Actively under development, with plans to ship to real communities within the next few months.

You can:

Star / fork the repo and open issues or PRs.
Comment here with questions or suggestions (especially around LMS‑specific UX, API patterns, or caching).
Follow as I keep shipping and documenting — if you’ve ever wondered what a “real‑sized” LMS architecture looks like at SaaS‑scale, this is a good place to watch it evolve.