Forem: Abdul Basit Muhyideen

🎭 Designing a User Model for Multiple Roles (Without Losing Your Mind)

Abdul Basit Muhyideen — Sun, 26 Oct 2025 21:57:12 +0000

You know that moment when your app suddenly needs more kinds of users?

You start with a simple User model — just name, email, password.
Life is peaceful. Everything makes sense.

Then your PM drops the bomb:

“We need admins, vendors, and customers.
And some users can be all three.”

Now you’re staring at your schema thinking,

“Maybe it’s time to switch careers.” 😅

Don’t panic — we’ve all been there.

In this post, we’ll design a clean, scalable, multi-role user system — the kind that won’t collapse the moment your startup adds a new user type.

We’ll explore:

The bad ideas (you’ve probably written before)
The better ideas
And finally, the best structure — one user table + separate profile tables.

🧱 1. The One-Table Disaster

Most apps start like this:

User {
  id: string
  name: string
  email: string
  password: string
  role: 'admin' | 'vendor' | 'customer'
  storeName?: string
  walletBalance?: number
}

It looks fine — until reality hits.

Customers don’t have storeName
Vendors don’t have walletBalance
Admins don’t need half the columns

Now your table looks like a junk drawer full of nullable fields.
Welcome to the God Table Anti-Pattern — one table trying to be everything, and doing nothing well.

🪓 2. The “Split Everything” Overcorrection

Then comes the overcorrection phase:

Admin { id, name, email, password, permissions }
Vendor { id, name, email, password, storeName }
Customer { id, name, email, password, walletBalance }

Looks cleaner, right?
Until you realize you just broke your system in three places.

Now you have:

3 login routes
3 sets of authentication logic
3 password reset flows

And worst of all:
A user can’t be both a vendor and a customer without two separate accounts. 🤦‍♂️

That’s not role-based — that’s multiple-account chaos.

💡 3. The Smarter Way — “User + Profiles”

Here’s the scalable approach:

Keep shared user data (like email, password, name) in a single User table.
Create separate tables for each role’s profile (AdminProfile, VendorProfile, CustomerProfile).
Let one user have multiple profiles linked to them.

Think of it like this:

The User is the person.
The Profiles are the hats they wear.

So, Sarah can:

Log in once ✅
Buy products as a customer 🛒
Sell items as a vendor 🏪
Manage users as an admin ⚙️

All through one account.

🧭 4. Visualizing It

          +------------------+
          |      User        |
          |------------------|
          | id               |
          | name             |
          | email            |
          | passwordHash     |
          +--------+---------+
                   |
          +--------+---------+
          |                  |
  +----------------+  +----------------+
  | VendorProfile  |  | CustomerProfile|
  |----------------|  |----------------|
  | id             |  | id             |
  | userId (FK)    |  | userId (FK)    |
  | storeName      |  | walletBalance  |
  | businessType   |  | preferences    |
  +----------------+  +----------------+

          +----------------+
          |  AdminProfile  |
          |----------------|
          | id             |
          | userId (FK)    |
          | permissions[]  |
          | accessLevel    |
          +----------------+

⚙️ 5. Schema Example (Prisma-style)

Here’s what that looks like in a clean ORM setup:

model User {
  id        String @id @default(uuid())
  name      String
  email     String @unique
  password  String
  createdAt DateTime @default(now())

  adminProfile    AdminProfile?
  vendorProfile   VendorProfile?
  customerProfile CustomerProfile?
}

model AdminProfile {
  id           String @id @default(uuid())
  userId       String @unique
  user         User   @relation(fields: [userId], references: [id])
  permissions  String[]
  accessLevel  String
}

model VendorProfile {
  id           String @id @default(uuid())
  userId       String @unique
  user         User   @relation(fields: [userId], references: [id])
  storeName    String
  businessType String
}

model CustomerProfile {
  id            String @id @default(uuid())
  userId        String @unique
  user          User   @relation(fields: [userId], references: [id])
  walletBalance Float
  preferences   String[]
}

It’s modular, readable, and future-proof.
Adding a new role later? Just create a new profile table. No migrations. No mess.

🧠 6. Real-World Example

Meet Sarah.
She signs up on your platform.

✅ Starts as a Customer → creates a CustomerProfile
🏪 Opens her store → creates a VendorProfile
⚙️ Joins your team → adds an AdminProfile

Still one login, one token, one user record.
She just switches context — your backend handles the rest.

🔍 7. Why This Wins

✅ Separation of concerns — shared auth, separate business logic.
✅ Extensible — new roles = new tables, not new headaches.
✅ Clean authorization — role checks happen on profile level.
✅ Reusable auth — login once, access multiple contexts.
✅ No null fields — because every role owns its own schema.

🚀 8. Wrapping Up

Good system design is like clean UI — invisible when done right.

This User + Separate Profile Tables approach gives you:

Flexibility
Scalability
And peace of mind 😌

As your app grows, you’ll thank yourself for choosing this pattern.

Because the next time someone says:

“We’re adding moderators now…”

You’ll just smile and create a ModeratorProfile table. 😎

💬 Coming Next

In the next article in this series:

Role-Based Access Control (RBAC) with User Profiles
— How to attach permissions dynamically and secure routes in your backend elegantly.

What Happens When You Type a URL in Your Browser? 🌐

Abdul Basit Muhyideen — Mon, 20 Oct 2025 22:01:40 +0000

What Happens When You Type a URL in Your Browser? 🌐

The unseen journey of your request — explained for developers.

You open your browser, type www.google.com, and boom — Google appears in seconds.

But what really happens in that tiny moment between hitting “Enter” and seeing the page load?

Behind the scenes, dozens of technologies and protocols spring into action. It’s like a relay race between your browser, DNS servers, routers, and Google’s data centers — all in milliseconds.

Let’s break it down step by step 👇

1. You Type the URL (and the Browser Gets to Work) 💻

When you type https://www.google.com and press Enter, your browser first breaks down that URL into pieces:

Protocol → https:// (how to communicate)
Domain name → www.google.com (where to go)
Path → /search (what resource to fetch, if any)

If it’s your first visit, the browser doesn’t know where www.google.com lives — so it has to find the IP address. That’s where DNS comes in.

2. DNS Lookup: Finding the Address 🗺️

The Domain Name System (DNS) works like the Internet’s phonebook.

When your browser asks, “Where is google.com?” it goes through these steps:

Browser Cache – Has it been visited recently? If yes, it already knows the IP.
OS Cache – If not, your computer’s operating system checks next.
Router Cache – Still not found? The router checks its local DNS cache.
ISP DNS Server – Finally, your Internet provider queries a global DNS system to find the IP (like 142.250.190.4).

Once found, the result is cached for faster access next time.

3. The Browser Opens a TCP Connection 🔗

Now that your browser knows Google’s IP address, it can connect.

It starts by creating a TCP connection — the reliable communication link of the Internet.
This is called the TCP handshake, and it happens in 3 steps:

SYN → Browser says, “Hey server, are you there?”
SYN-ACK → Server replies, “Yes, I am. Ready?”
ACK → Browser confirms, “Let’s talk!”

This ensures both sides are ready to exchange data safely.

4. HTTPS & TLS Handshake: Secure the Channel 🔒

Because the URL uses HTTPS, the connection must be secure.

So, after the TCP handshake, the browser and server perform a TLS handshake (Transport Layer Security):

The server sends its SSL certificate to prove its identity.
The browser verifies the certificate (checking if it’s valid, trusted, and matches the domain).
Both agree on encryption keys to secure the session.

Once this is done, all data sent between your browser and the server is encrypted.

5. Sending the HTTP Request 📩

Finally, your browser sends an HTTP request to the server.

Example:

GET / HTTP/1.1
Host: www.google.com
User-Agent: Chrome/120.0
Accept: text/html

This tells the server:

The method (GET) — “I want to read something.”
The resource (/) — the homepage.
Browser details and supported content types.

6. The Server Processes the Request ⚙️

On Google’s end, powerful web servers receive your request.

Here’s what happens there:

The server routes your request to the correct backend service (for example, Google Search).
Backend logic runs — retrieving data, rendering pages, calling APIs.
The server generates a response, typically in HTML (or JSON for APIs).

Example response:

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

And then comes the HTML document — the skeleton of the web page.

7. Browser Renders the Page 🧠

Once your browser receives the response, it gets busy again:

HTML Parsing – Reads the HTML and builds the DOM (Document Object Model).
CSS Parsing – Loads styles and builds the CSSOM.
JavaScript Execution – Runs scripts that may modify the DOM or fetch more data.
Layout & Painting – Figures out where everything goes and paints pixels to your screen.

This is when you see the website appear — text, images, buttons, all beautifully arranged.

8. More Requests Behind the Scenes 🔁

Even after the main HTML loads, the browser continues fetching:

Images (.jpg, .png)
CSS stylesheets
JavaScript files
Fonts
APIs for dynamic data

Each of these makes its own HTTP request to the server (or CDNs). That’s why browsers load resources in parallel for speed.

9. Caching, Cookies, and Performance 🍪

Before finishing, the browser checks caching rules:

Cache-Control headers decide if the resource can be reused.
Cookies might be stored or sent back for authentication or personalization.
Compression (like GZIP or Brotli) helps reduce file sizes for faster loading.

All these optimizations ensure that the next visit feels instant.

10. You See the Page ✨

And there you have it — a full journey completed in under a second!

From typing a URL to seeing a page, here’s what just happened:

You entered a URL
DNS resolved the domain
TCP & TLS handshakes secured the channel
HTTP request sent
Server processed and responded
Browser rendered and displayed the content

All these layers work together — perfectly synchronized — to give you the illusion of instant access.

Wrapping Up 🎯

Every time you type a URL, you trigger an orchestra of systems, protocols, and servers that collaborate to deliver what you see.

For backend engineers, understanding this flow is gold:

You’ll know where latency creeps in.
You’ll grasp how APIs communicate.
You’ll understand why DNS, SSL, and caching matter so much.

Next up in the series: “Understanding HTTP and HTTPS — The Internet’s Communication Language.” 🚀

How the Internet Works (Simplified for Developers)

Abdul Basit Muhyideen — Sun, 05 Oct 2025 21:03:14 +0000

Ever wondered what really happens when you hit “Send” on WhatsApp, or type google.com into your browser?
Spoiler: your data doesn’t just teleport. The Internet is more like the world’s busiest postal system—except instead of envelopes and delivery trucks, we have packets, routers, and cables running under the ocean.

As backend engineers, this isn’t just trivia. The Internet is the foundation for APIs, databases, and cloud apps. Let’s break it down — no jargon overload, just the essentials.

The Internet as a Giant Network 🌍 Think of the Internet as a massive web of connected computers — servers, laptops, phones, IoT devices. These devices talk to each other through wires, fiber optics, satellites, and wireless signals.

👉 Analogy: Every device is like a house, and the data you send is a letter. The Internet is the postal system making sure it gets delivered.

Data Travels as Packets 📦 When you send a message or load a webpage, your data doesn’t travel in one big piece. Instead, it’s broken into small chunks called packets.

Each packet carries:

A piece of your data (like a puzzle piece)
The sender’s address (your IP)
The receiver’s address (destination IP)

Packets often take different routes through the network and get reassembled at the destination.

IP Addresses = Digital Street Addresses 🏠 Every device online has an IP address (like 192.168.0.1 or 2607:f8b0::).

IPv4: Old system, running out of addresses
IPv6: Modern system, almost unlimited addresses
Without IP addresses, your data wouldn’t know where to go.

DNS: The Internet’s Phonebook ☎️ Humans don’t like memorizing IPs (172.217.5.110 isn’t fun). Instead, we use domain names like google.com.

The Domain Name System (DNS) is like a phonebook — it translates names into addresses.
So when you type google.com, DNS quietly finds its IP for you.

The Internet’s Infrastructure ⚙️ Behind the scenes, the Internet is powered by:

ISPs: Give you access (your local “post office”)
Routers & Switches: Direct traffic
Servers & Data Centers: Store and serve content
Undersea Cables & Satellites: Connect continents

Fun fact: Most of the Internet’s traffic actually travels through underwater cables, not satellites.

Protocols: The Rules of Communication 📡 Computers don’t just “wing it.” They follow strict rules called protocols:

TCP/IP: Splits data into packets, ensures delivery
HTTP/HTTPS: Browser ↔ server communication
SMTP: Emails in action

Think of protocols as the grammar of the Internet — without them, computers would just be babbling nonsense.

Wrapping Up 🎁
At its core, the Internet is:

A network of devices (the houses)
Sending packets of data (letters)
Across infrastructure (roads, post offices)
Using protocols (the rules of delivery)

For backend engineers, this foundation explains why APIs work, why latency exists, and how scaling apps ties back to the Internet’s plumbing.

Next up in this series: “What Happens When You Type a URL in Your Browser?” 🔥