Forem: Muhammad Ibtisam

How Modern Systems Are Built: A Complete System Design Guide

Muhammad Ibtisam — Tue, 05 Aug 2025 14:02:58 +0000

“System Design isn’t about memorizing terms. It’s about solving one problem and discovering another.”

Here’s a complete journey, starting from the first user request and going all the way to a massive, scalable, real-time backend — explained in simple words, step-by-step.

1️⃣ Client-Server Architecture

Let’s start from the very beginning.
You’re building an app — maybe a shopping website or a ride-booking app.

The app that users see on their screen (called the client) needs to get data — like products, users, prices — from a server (a remote computer).

This is called the Client-Server Architecture. The client asks, the server responds.

But now a big question arises…

2️⃣ IP Address

How does the client find the server?

Just like houses need home addresses, servers need unique numbers called IP addresses. These are how data knows where to go.

But here’s the problem: humans can't remember IPs like 192.0.2.1.

So we need a better system…

3️⃣ DNS (Domain Name System)

DNS is like the contact list on your phone.
You don’t remember phone numbers — you just type names. Similarly, DNS converts facebook.com into its real IP address.

Without DNS, we’d all be typing weird numbers instead of website names.

Now that the client has the server’s address… can it go straight to it?

4️⃣ Proxy / Reverse Proxy

Not always.
In big systems, we place a Reverse Proxy (like NGINX) in front of the actual server. It’s like a receptionist for your backend.

It:

Filters unwanted traffic
Caches common responses
Distributes load
Hides internal server info

This makes your system safer and more efficient.

But now, as requests start flowing… we want speed.

5️⃣ Latency

Latency is the time between a user clicking something and getting the response.
Slow systems frustrate users.

Every step — DNS, proxy, server response — adds to latency.

So we must send only what’s needed, as efficiently as possible.

That’s where protocols come in.

6️⃣ HTTP / HTTPS

Clients and servers “talk” using a language called HTTP.
But this talk must be secure, so we wrap it with encryption. That becomes HTTPS.

It ensures no one in the middle (like hackers) can read sensitive data.

But now, how do we define what the client can ask for?

7️⃣ APIs

An API is like a restaurant menu.
It tells the client exactly what it can request — and what it’ll get in return.

APIs are the rules of communication between frontend and backend.

But how should we organize those rules?

8️⃣ REST API

REST is a style of designing APIs.
It uses:

URLs like /users/123
HTTP methods like GET, POST, PUT, DELETE
Clean, predictable structure

REST is great for most apps.

But for complex or mobile apps, REST can feel a bit heavy.

9️⃣ GraphQL

With GraphQL, the client can ask for exactly the data it needs — nothing more, nothing less.

It’s perfect when:

You have many frontend devices (web, mobile, smart TVs)
You want fewer requests
You need fine control over the response

Both REST and GraphQL talk to… the database.

🔟 Databases

The Database is where your system remembers everything:
Users, products, messages, orders — all go here.

Without it, your system has no memory.

But what kind of database should you use?

1️⃣1️⃣ SQL vs NoSQL

SQL (like PostgreSQL): Data stored in rows and columns, strict rules, great for transactions.
NoSQL (like MongoDB): More flexible, handles lots of data quickly, perfect for huge apps.

But as data grows… performance drops.

So how do we handle more users?

1️⃣2️⃣ Vertical Scaling

First, we try Vertical Scaling: upgrading the server’s RAM, CPU, storage.

It’s like upgrading your laptop to make it faster.

But there’s a limit to how much you can upgrade.

1️⃣3️⃣ Horizontal Scaling

So we do Horizontal Scaling: adding more servers instead of one big one.

Imagine instead of one huge shop, you open 10 smaller ones.

But now… how do you divide the work among them?

1️⃣4️⃣ Load Balancers

Load Balancers sit in front of all your servers and divide traffic evenly.

They:

Send each user request to the best-performing server
Help handle failures
Improve reliability

Great. But now your database is under pressure.

1️⃣5️⃣ Database Indexing

Indexes help databases find data faster — just like a book index.

Instead of reading the whole table, the DB jumps directly to what it needs.

But even with indexing… traffic can overwhelm the database.

1️⃣6️⃣ Replication

We replicate the database:

One copy for writing
Multiple copies for reading

This makes the system faster and safer. If one DB crashes, others still work.

Still, with massive data, one DB instance isn’t enough.

1️⃣7️⃣ Sharding

You split the data into parts, called shards.
Each shard holds only a slice of the total data (e.g., by region or user ID).

Now, instead of one overloaded DB, you have many smaller, faster ones.

But it gets hard to manage mixed data in one table…

1️⃣8️⃣ Vertical Partitioning

You separate data into logical parts.

Example:

One DB for user profiles
Another for payment history
Another for analytics

It makes data cleaner and services more focused.

But queries are still heavy. We need speed.

1️⃣9️⃣ Caching

You add a cache (like Redis) to store recently used data in memory.

It’s way faster than hitting the database every time.

Example: homepage products, popular posts, session info.

But even joining tables slows things down.

2️⃣0️⃣ Denormalization

Now you duplicate some data across tables to reduce joins.

Yes, it breaks some rules…
But it makes reads blazingly fast — and users happy.

But let’s say your system spans across continents now…

2️⃣1️⃣ CAP Theorem

In big, distributed systems, you can’t have:
✅ Perfect consistency
✅ Always available
✅ Handle network breaks

You must choose two.

This shapes how you design your system — whether to prioritize accuracy or uptime.

Now, what if users upload files?

2️⃣2️⃣ Blob Storage

Large files (images, videos, PDFs) don’t belong in your DB.

You move them to Blob Storage like AWS S3.
It’s cheap, fast, and built for this.

But how do we deliver those files faster?

2️⃣3️⃣ CDN (Content Delivery Network)

CDNs store static content closer to your users around the world.
This means faster load times and lower server load.

Essential for performance-focused apps.

Now… what if your app needs real-time updates?

2️⃣4️⃣ WebSockets

WebSockets keep a live connection open between client and server.

Perfect for:

Live chat
Multiplayer games
Trading dashboards

But what about notifying other services?

2️⃣5️⃣ Webhooks

Webhooks let one app notify another when something happens.
E.g., Stripe pings your app when a payment succeeds.

But your app is huge now. Time to break it down.

2️⃣6️⃣ Microservices

You split your app into microservices:
Each handles one feature — users, orders, inventory, etc.

It’s easier to develop and scale independently.

But how do these services talk?

2️⃣7️⃣ Message Queues

Instead of direct calls, services communicate via message queues (like Kafka, RabbitMQ).

This helps with:

Reliability
Retry logic
Loose coupling

Still… people can abuse your APIs.

2️⃣8️⃣ Rate Limiting

You set a limit on how many requests one user can send in a given time.

This stops:

Spammers
DDoS attacks
Accidental loops

This is often done at the gateway…

2️⃣9️⃣ API Gateway

An API Gateway is a single front door to all your microservices.

It handles:

Routing
Authentication
Rate limiting
Logging

But what if a request is repeated?

3️⃣0️⃣ Idempotency

An idempotent operation can run multiple times without changing the result.

Example: If a payment is retried, you don’t want to charge the user twice.

This protects users from bugs and poor networks.

🧩 Summary

Each system design concept solves a problem…
But creates a new one that needs a better solution.

That’s how systems grow.

How to Use the Intersection Observer API for Scroll-Based Animations in JavaScript

Muhammad Ibtisam — Wed, 23 Jul 2025 11:37:51 +0000

🚀 Today I Learned: Intersection Observer API in JavaScript 👨‍💻

As a developer, I'm always looking for ways to improve performance and user experience — and today I explored something incredibly useful: the Intersection Observer API.

🧠 Why It's Awesome

Instead of relying on expensive scroll event listeners, the Intersection Observer API provides a modern, efficient way to detect when an element enters or exits the viewport.

✨ Use Cases:

✅ Lazy-loading images
✅ Triggering animations on scroll
✅ Infinite scroll implementations
✅ Tracking element visibility for analytics

It's clean, lightweight, and extremely helpful for modern web apps and SPAs.

🎥 Live Demo (Scroll Animation)

I created a quick example that triggers animations when elements come into view, using Intersection Observer and Tailwind CSS.

▶️ Watch the Loom video demo

💻 GitHub Code

If you'd like to check out the code or try it yourself, here’s the repo:

🔗 GitHub Repository – JS_Intersection_Observer_API

💬 Let’s Talk!

Have you used the Intersection Observer API in your projects?

Any interesting tricks, animations, or use cases?

Drop your thoughts in the comments — I’d love to learn from your experience!

Database Design Mistakes I Wish I Avoided Earlier

Muhammad Ibtisam — Tue, 22 Jul 2025 11:30:02 +0000

🧩 Introduction

When I first started building full-stack apps, I thought database design was just about creating tables and throwing in some columns.
I was wrong — and it cost me time, performance, and even features.

In this post, I’ll share the most painful database design mistakes I made early in my journey, and how you can avoid them.

🚫 Mistake #1: Not Planning the Schema First

❌ What I did:

I jumped straight into writing backend logic before thinking about how the data should be structured.

💡 Why it’s bad:

This leads to inconsistent models, extra refactoring, and broken features later on.

✅ What to do instead:

Sketch your schema first (pen & paper, Notion, or dbdiagram.io)
Think in terms of entities and relationships before writing a single query

🚫 Mistake #2: Ignoring Relationships (Trying to Be Too "Flexible")

❌ What I did:

I used MongoDB and thought, “I’ll just embed everything.” No references, no structure — just vibes.

💡 Why it’s bad:

Hard to query
Impossible to scale
Duplication of data everywhere

✅ What to do instead:

Learn when to embed vs reference (especially in NoSQL)
Use relational principles even in NoSQL when it makes sense

🚫 Mistake #3: No Indexing (Performance Killer!)

❌ What I did:

I thought indexing was an optional “optimization” for later.

💡 Why it’s bad:

As soon as data grows, queries slow down
Some simple pages took 5+ seconds to load because the DB was scanning everything

✅ What to do instead:

Add indexes on commonly queried fields (like email, userId, createdAt)
Monitor slow queries and optimize them

🚫 Mistake #4: No Migrations or Version Control

❌ What I did:

I manually changed the database structure whenever I needed to “fix” something.

💡 Why it’s bad:

You lose track of what changed
Production and dev DBs go out of sync
Hard to onboard teammates or redeploy

✅ What to do instead:

Use tools like Prisma, Sequelize, Knex, or TypeORM
Write migration scripts or use auto-migration tools
Version your DB the way you version your code

🚫 Mistake #5: Storing Everything in One Table

❌ What I did:

For “simplicity,” I used one big collection/table to store different types of data (e.g., notifications, messages, logs).

💡 Why it’s bad:

Makes querying messy
No data isolation or structure
Tough to manage permissions and logic

✅ What to do instead:

Create a separate table/collection per distinct entity
Normalize your data, then denormalize only where needed

🧠 Bonus Tip: Learn to Think in Queries

Even with the perfect schema, if you don’t know how you’ll query the data, you’ll hit roadblocks.

Before finalizing your schema, ask:

“Can I get the data I need easily and efficiently?”

If not, go back and tweak your design.

🔚 Conclusion

Bad database design won’t break your app on day one — but it will break it when you scale, add features, or try to optimize performance.

Now that I’ve learned these lessons (some the hard way), I always treat DB design as step one, not an afterthought.

If you're just getting started, take the time to plan, structure, and index wisely — your future self will thank you.

Is Your App Struggling with More Users? This Might Be Why.

Muhammad Ibtisam — Mon, 21 Jul 2025 12:20:43 +0000

Your app works fine with a few users.
But when traffic increases — it gets slow, crashes, or feels laggy.

If that sounds familiar, the issue might not be your code — it could be your scaling strategy.

Here’s a quick breakdown of two common ways apps scale:
Vertical Scaling and Horizontal Scaling — explained in simple terms.

🚀 Vertical Scaling (Scaling Up)

This means upgrading the same server to make it more powerful.
You increase its RAM, CPU, or storage — basically giving it more strength.

Why it’s useful:

It’s very easy to do — you just click “upgrade” in your hosting provider.
You don’t need to change anything in your code.
Perfect for small apps or MVPs that aren’t under heavy traffic yet.

Where it struggles:

There's a limit. You can’t keep upgrading forever — hardware caps out.
If the server goes down, your whole app is offline — because you’re relying on just one machine.

Example:
You build a MERN stack app and host it on a 1GB server.
When users grow and the app slows down, you increase it to 4GB RAM. That’s vertical scaling.

📦 Horizontal Scaling (Scaling Out)

This means adding more servers and splitting your app across them.
Instead of one big server, you now have multiple smaller ones sharing the load.

Why it’s powerful:

It improves speed and performance under high traffic.
If one server fails, others keep the app running — more reliable.
You can grow endlessly by adding more servers over time.

Why it’s harder:

It requires some setup: load balancers, shared storage, etc.
You might need to update your code — like storing sessions in Redis instead of in memory.

Example:
You deploy your backend on 3 different servers, and use Nginx to route traffic between them.
Each server handles part of the user load — that’s horizontal scaling.

💡 Which Should You Use?

If you're just starting out or have a small user base, vertical scaling is quick, simple, and cheap.

But if your app is growing fast, or you need high uptime and better performance under load, then you’ll eventually need horizontal scaling.

Many apps start by scaling vertically — and switch to horizontal scaling as traffic grows.

✅ Final Thought

If your app slows down as users grow, take a moment to review how you’re scaling.
Sometimes the fix isn't in your code — it's in how your servers are set up.

A smart scaling strategy can save you time, money, and a lot of frustration later on.

I Skipped System Design and Paid the Price 💥 A Hard Lesson Every Developer Learns

Muhammad Ibtisam — Sun, 20 Jul 2025 12:53:26 +0000

Why system design matters even before you write a single line of code — a personal story every developer should read.

I used to jump straight into coding.

No plan. No structure. Just vibes. 😅

And at first, it felt great.

💻 I was writing code fast

📱 Screens were showing up

⚙️ APIs were working

It felt like progress... until it wasn’t. 😬

🚨 Then Everything Started Falling Apart

A few weeks later, things broke down:

🔁 Every new feature broke something else

🧩 Code became a tangled mess

🐢 App performance slowed down

I started asking myself:

"Why didn’t I plan this properly from the beginning?" 🤦‍♂️

💥 That’s When I Realized

👉 System Design matters

🧠 Clear requirements matter even more

It wasn’t just bad code.

I didn’t even fully understand what I was building.

❌ No clear goals

❌ No user flow

❌ No big picture

💭 Whether You’re Working On...

👨‍💻 A client project

🚀 A startup idea

🛠️ Your own side hustle

If you don’t plan first, you’ll end up wasting time fixing things later. 😤

And no — I’m not talking about fancy diagrams or huge documents. 📄✖️

🗺️ Even a Rough Sketch Helps

Just outlining:

How your app works
How data moves
What the user actually needs

Can save you so much trouble later.

✅ Now I Do Things Differently

I don’t start coding until:

✅ I know what the project needs

✅ I’ve mapped out the basic flow

✅ I’ve asked the right questions

And honestly? It makes everything smoother. 🙌

👇 Have You Been There Too?

Have you ever jumped into code too early and regretted it later?

Let me know in the comments — or share what you do differently now. I'd love to learn from your experiences too!