DEV Community: Sajidur Rahman Shajib

🔄 Push vs Pull Architecture: What’s the Real Difference?

Sajidur Rahman Shajib — Thu, 24 Jul 2025 20:28:08 +0000

In software architecture, Push and Pull models define how data flows between a producer (like a server) and a consumer (like a client). While both are valid, choosing the right one can significantly impact user experience, system performance, and scalability.

📤 What is Push Architecture?

In a Push model, the server initiates the communication. It sends (or "pushes") data to the client whenever something new happens. The client doesn’t have to ask—it just gets notified.

✅ Pros:

Low latency
Real-time experience
Efficient for frequent updates

❌ Cons:

More complex to implement
Harder to scale with many clients

🧠 Examples: WebSockets, Firebase Realtime Database, Server-Sent Events

📥 What is Pull Architecture?

In a Pull model, the client initiates the communication. It regularly or occasionally requests data from the server, asking, “Do you have anything new?”

✅ Pros:

Simpler and more predictable
Easier to cache and scale

❌ Cons:

Higher latency (delays)
Might miss real-time events

🧠 Examples: REST APIs, GraphQL, Cron Jobs

👩‍💻 Alice’s Story: Choosing Between Push and Pull

Alice is a full-stack developer working on two features for her startup’s new app:

1. 🔔 Real-Time Notifications (Push)

She wants users to get live alerts when someone likes their post. She builds this using WebSockets so that once a user is connected, the server can immediately push the like notification to their screen.

🧠 No polling. Instant updates. Smooth UX.

2. 📊 Weekly Reports Dashboard (Pull)

For analytics, users only care about their weekly activity. Alice decides to build this with a simple REST API that the frontend calls when the user opens the dashboard. The data is pulled on demand.

💡 No need to keep a live connection for static weekly reports.

Alice sees the strengths and trade-offs of both models firsthand.

🧮 Push vs Pull: Head-to-Head

Aspect	🔄 Push	🔁 Pull
Initiator	Server	Client
Data Delivery	Real-time	On-demand
Latency	Low	Can be high
Complexity	Higher	Lower
Best For	Live feeds, chat, notifications	Reports, forms, content APIs
Examples	WebSocket, Firebase	REST API, GraphQL

🧠 Conclusion: Which One Should You Use?

As Alice learned, there's no one-size-fits-all. Use Push when you need instant updates. Use Pull when your app can tolerate a delay or doesn’t change often.

💭 As a developer, ask yourself:

“Does my user need this data now, or can it wait?”

That question might just guide you to the right architecture. 😉

🌐 Proxy vs Reverse Proxy – Explained Simply with Alice 🧠

Sajidur Rahman Shajib — Mon, 14 Jul 2025 14:35:14 +0000

When you hear the terms Proxy and Reverse Proxy, it might sound like network jargon. But don't worry—let’s break it down in plain English, and better yet, let's bring in Alice to help us understand it like a story.

🔍 What Is a Proxy?

A Proxy (Forward Proxy) is like a middleman between you (the client) and the internet. When you use a proxy, you're not directly talking to the website—you send the request to the proxy, and it fetches the site for you.

Key Point: It hides the client (you) from the internet.

🔁 What Is a Reverse Proxy?

A Reverse Proxy is the opposite. It sits in front of servers and handles incoming requests. It decides which server should process the request and then responds back to the client.

Key Point: It hides the servers from the client.

🧵 The Story: Alice and the Library 📚

Scene 1: Alice Uses a Proxy

Alice lives in a country where some websites are blocked. She really wants to read a blog hosted abroad.

So, she asks her tech-savvy friend Bob to help.

Bob says, “Use this proxy server I set up. Instead of visiting the site directly, tell the proxy what you want. It’ll grab the page and show it to you.”

Now, the website thinks the proxy is the visitor, not Alice. Alice stays anonymous.

🧠 This is a forward proxy.

Scene 2: Alice Builds a Website

Alice starts her own website. It becomes popular and crashes often. So she deploys 3 servers behind a reverse proxy.

Now, when visitors go to aliceblog.com, the reverse proxy handles the traffic, picks one of the backend servers, and returns the response.

Visitors never know which server handled their request—they only see aliceblog.com.

🧠 This is a reverse proxy.

💡 Practical Use Cases

✅ Proxy (Forward Proxy)

🛡️ Privacy & Anonymity
- Hide IP while browsing
- Access blocked content
🏫 Network Control
- Schools and offices block websites (e.g., Facebook)
- Monitor and log browsing activity
📈 Web Scraping
- Rotate IPs via proxy pools to avoid detection
📦 Caching
- Cache frequently accessed pages to save bandwidth

✅ Reverse Proxy

📊 Load Balancing
- Distribute traffic across multiple backend servers
🔒 SSL Termination
- Handle HTTPS encryption at the proxy level
🧱 Security
- Hide internal server structure from the outside world
⚡ Faster Content
- Serve static content (CSS, JS, images) directly
🎯 API Gateway
- Unified entry point for multiple services (common in microservices)

🚀 Summary

Feature	Proxy (Forward)	Reverse Proxy
Who it hides	Hides the client	Hides the server
Used by	Client	Server or network
Purpose	Anonymity, filtering	Load balancing, security

Whether you're scraping the web, protecting your infrastructure, or optimizing load, understanding proxies will give you an edge in modern web development.

Now you're thinking like Alice. Stay curious. 🧠💡

🧩 When to Use NoSQL and SQL?

Sajidur Rahman Shajib — Sun, 13 Jul 2025 12:42:51 +0000

Choosing between SQL and NoSQL isn’t about which one is better—it’s about which one fits your project best. Let’s break it down in a clear, no-fluff way.

🧠 What is SQL?

SQL (Structured Query Language) databases are relational—they organize data in tables with predefined schemas. They’re great for handling structured data, maintaining relationships, and ensuring data integrity.

🛠️ Popular SQL Databases: PostgreSQL, MySQL, SQLite, SQL Server

🌐 What is NoSQL?

NoSQL (Not Only SQL) databases are non-relational, designed for flexibility and scalability. They store data as documents, key-value pairs, wide-columns, or graphs—perfect for dynamic, high-speed applications.

⚙️ Popular NoSQL Databases: MongoDB, Redis, Cassandra, DynamoDB

📌 When to Use SQL

Use SQL when:

✅ Your data is structured and predictable
🔗 You need relationships between entities (users → orders)
🧾 Complex queries and reporting are required
🧪 You need ACID transactions (reliable and consistent)
📊 You care about data integrity and validation

Example Use Cases:

Banking systems 💸
Inventory management 📦
E-commerce platforms 🛒
ERP or CRM systems 🧾

📌 When to Use NoSQL

Use NoSQL when:

🔄 Your data is dynamic or semi-structured
🚀 You need high write/read throughput
🌍 Your app must scale across distributed systems
⚡ Schema needs to evolve quickly
⏱️ You care more about availability & speed than strict consistency

Example Use Cases:

Chat and messaging apps 💬
Real-time analytics 📈
IoT data and logs 📡
Caching systems 🔥

⚖️ SQL vs NoSQL — Side-by-Side

Feature	SQL	NoSQL
Structure	Relational (tables)	Flexible (docs, key-value, etc.)
Schema	Fixed	Dynamic
Relationships	Strong (JOINs)	Weak or manual
Query Language	SQL	Varies (MongoQL, etc.)
Scaling	Vertical (scale-up)	Horizontal (scale-out)
Transactions	ACID	BASE (eventual consistency)
Use Case Fit	Financial, inventory, ERP	Real-time, IoT, big data

💡 Final Tip

🛠️ Modern systems often use both:

SQL for core business data
NoSQL for speed, flexibility, or caching

Don’t choose based on trend—choose based on need.

That’s smart engineering. 🚀

Written for devs who want to architect better systems.

🧠 Understanding the CAP Theorem – Through Alice’s Distributed Adventure 🚀

Sajidur Rahman Shajib — Sat, 12 Jul 2025 21:26:44 +0000

Distributed systems are everywhere — from your favorite social media platforms to online banking. But making them work reliably isn’t easy. One foundational concept every backend engineer or system designer needs to understand is the CAP Theorem.

📚 What is the CAP Theorem?

CAP stands for Consistency, Availability, and Partition Tolerance. Proposed by Eric Brewer in 2000, the CAP Theorem states that:

In any distributed data system, you can only guarantee two out of the following three properties at the same time:

Consistency (C): Every node sees the same data at the same time.
Availability (A): Every request gets a response — success or failure.
Partition Tolerance (P): The system continues to function even if network issues split it into disconnected parts.

When a network partition occurs (and it will, eventually), you’re forced to choose between Consistency and Availability.

🧵 Alice and the CAP Dilemma: A Distributed Tale

Meet Alice, a backend engineer working at a startup called BDGrocer, which delivers groceries in real-time using microservices.

One day, Alice was tasked with designing a distributed order system that would sync between the Dhaka and CTG servers. Simple? Not quite.

🔧 Round 1: The Ideal World

Alice dreams of a perfect system where:

All users always see the most recent order status (Consistency).
Every request is responded to immediately (Availability).
And of course, the system survives any network failure (Partition Tolerance).

But then her senior smiles and says:

“Alice, welcome to CAP. You can only pick two.”

⚖️ Option 1: Consistency + Partition Tolerance (CP)

Alice thinks, “Let’s make sure data is always accurate, even if servers get partitioned.”

If Dhaka and CTG servers can't talk due to a network glitch, she decides to block requests to avoid stale data.
Customers might wait a bit longer, but they'll get the right info.

📉 Trade-off: The system isn't always available. Some users might get errors or timeouts.

Use case: Financial systems like banks — better to fail than show wrong balance.

⚡ Option 2: Availability + Partition Tolerance (AP)

Now Alice thinks, “Speed is key. Let’s answer all requests, even if the servers are split.”

If there's a partition, both servers still serve requests.
But data might temporarily be inconsistent (e.g., one user sees their order canceled, the other sees it confirmed).

📉 Trade-off: Some temporary inconsistency, but system is always responsive.

Use case: Messaging apps — better to let users keep chatting and sync later.

✅ Option 3: Consistency + Availability (CA)

Alice likes this. No data mismatch, and always responsive! But then...

🚨 Oops: It only works if there's no network partition. Not realistic in distributed systems.

Conclusion: CA works only in single-node or non-partitioned setups. In real distributed systems, you must tolerate partitions — so this combo isn’t practical.

🧠 What Did Alice Learn?

In the real world, network partitions are inevitable. So most distributed systems must pick between C or A — they can’t have both when the network fails.

Alice wisely chooses different trade-offs for different services:

For payments, she picks CP.
For live delivery tracking, she goes with AP.

🎯 Final Thought

Understanding CAP isn't about memorizing acronyms — it's about making smart trade-offs. Each choice fits a different context. Like Alice, you should always ask:

“What matters most here — accuracy or availability — when the network goes wrong?”

That’s how real-world systems are built. 🚀

🚀 A Better Way to Seed Data Using SQLAlchemy (Async-friendly)

Sajidur Rahman Shajib — Tue, 01 Jul 2025 20:32:18 +0000

In modern backend projects, especially with FastAPI and async SQLAlchemy, seeding initial data like (e.g.,roles) is an important part.

Here’s a practical and scalable approach we used to seed data smoothly:

✅ 1. Organized Seeders
Each seeder reads data from JSON files and checks if the entry already exists in the DB. If not, it creates it — avoiding duplicates.

[
    {
        "role": "admin"
    },
    {
        "role": "manager"
    },
    {
        "role": "developer"
    },
    {
        "role": "user"
    }
]

# roles_seeder.py
import json
import os

from sqlalchemy.ext.asyncio import AsyncSession
from sqlalchemy.future import select

from app.models.roles import Role


async def seed_roles(session: AsyncSession):
    try:
        json_path = os.path.join(
            os.path.dirname(__file__), 'data', 'roles.json'
        )
        with open(json_path, 'r') as file:
            roles_to_seed = json.load(file)

        for role_data in roles_to_seed:
            role_name = role_data.get('role')

            if not role_name:
                print("[-] Skipping invalid role data: missing 'role'.")
                continue

            existing_role_query = await session.execute(
                select(Role).where(Role.role == role_name)
            )
            existing_role = existing_role_query.scalars().first()

            if not existing_role:
                print(f"[+] Creating new role '{role_name}'.")
                new_role = Role(role=role_name)
                session.add(new_role)

        await session.commit()
        print('[+] Roles seeded or updated successfully.')
    except Exception as e:
        await session.rollback()
        print(f'[-] Error while seeding or updating roles: {e}')
        raise

Note: Your code might be different based on your requirements.

✅ 2. Shared Async Context
We centralize DB session logic using sessionmanager to handle init/close properly with async SQLAlchemy.

# cli.py
import asyncio

import typer

from app.seed.articles_seeder import seed_articles
from app.seed.categories_seeder import seed_categories
from app.seed.roles_seeder import seed_roles
from app.services.config import config
from app.services.connection import sessionmanager

cli = typer.Typer()


async def run_seed(func):
    sessionmanager.init(config.db_dsn)
    async with sessionmanager.session() as session:
        await func(session)
        await session.commit()
    await sessionmanager.close()


@cli.command()
def roles():
    asyncio.run(run_seed(seed_roles))


@cli.command()
def categories():
    asyncio.run(run_seed(seed_categories))


@cli.command()
def articles():
    asyncio.run(run_seed(seed_articles))


if __name__ == '__main__':
    cli()

✅ 3. CLI with Typer
Typer gives us a clean CLI to run seed commands like:

python3 cli.py roles

✉️ Conclusion:

I didn’t go into too much detail here—just shared the core code for you to copy and use. Hopefully, you’re already familiar with Python and SQLAlchemy.

🐍 Don't Need to Create requirements.txt and .venv Manually [UV]

Sajidur Rahman Shajib — Sun, 22 Jun 2025 11:47:01 +0000

We need something better than pip — and that's where uv comes in. It’s a fast Python package manager and task runner that replaces pip, venv, and even parts of poetry, without the extra overhead.

Though previously I wrote Do not use 'pip freeze' and Best way to create requirements.txt. You can read them...

🏁 First install `uv`

You can find the installation instructions for uv here

🔧 `uv init`: Instant Project Setup

uv init

This command creates a boilerplate pyproject.toml and sets up your .venv — no manual steps needed. It automatically detects your Python version and prepares a minimal project environment.

➕ uv add: Add Dependencies Instantly

Need a package like rich?

uv add rich

This adds it to your pyproject.toml, installs it, and updates your uv.lock. No need to touch requirements.txt.

Example usage with rich:

from rich import print

print("[bold green]Hello from UV-powered project![/bold green]")

🚀 uv run: Run with Environment

Instead of manually activating .venv, use:

uv run main.py

This runs your app inside the managed environment automatically.

Yes, you can still run with python main.py, but that means you'll have to activate .venv manually:

source .venv/bin/activate

🔄 After Clone/Pull a UV based project

First run

uv venv

and then install all packages from pyproject.toml

uv sync

📚 Want More?

There’s more you can do: uv pip, uv pip freeze, uv sync --update, and more. You can even change Python versions or set a specific version in .python-version — check it out in their docs.

🧠 What are Pages (in OS/memory)?

Sajidur Rahman Shajib — Mon, 09 Jun 2025 03:31:06 +0000

A page is a fixed-length block of virtual memory. When discussing threads, processes, and system memory, paging is a memory management scheme that eliminates the need for contiguous memory allocation.

🔹 Key Points:

Size: Typically 4 KB (can be 2 MB or more in modern systems).
Virtual Memory: Programs access memory using virtual addresses, which the OS maps to physical memory using pages.
Page Table: Maintains the mapping between virtual pages and physical frames.
Swapping: When RAM is full, the OS can move pages to disk (swap space), making room for active data.
Benefits: Prevents fragmentation and allows efficient use of memory.

*** 📦 Real-world analogy:
Think of memory as a book (RAM) and each page in the book is… a page. Programs don't care which physical page they're using; they just read "Page 5", and the OS finds the right actual page in the book.

If you meant something else by “pages” (e.g., web pages), let me know. But in this HLD/fundamentals context, it's almost certainly memory pages

🧪 Understanding the ACID Properties in Databases

Sajidur Rahman Shajib — Mon, 09 Jun 2025 02:50:36 +0000

🔍 What is ACID?

ACID stands for Atomicity, Consistency, Isolation, Durability — four key properties that ensure reliable, safe, and predictable database transactions.

Together, they guarantee that your data remains accurate and stable, even in the face of errors or system crashes.

📖 A Short Story to Explain ACID

Imagine a user named Alice is signing up on your website. Here's what happens behind the scenes:

A row is added to the users table.
A matching row is created in the profile table with default info.
A welcome product is added for her in the products table.

Now let’s walk through ACID using this scenario:

🧩 A - Atomicity

All or nothing. Either the entire operation completes, or nothing does.

💡 If Alice's users entry is created but something fails while inserting into the profile table, Atomicity ensures that the entire signup is rolled back — no partial data!

🛡️ C - Consistency

Data must move from one valid state to another, maintaining all rules and constraints.

💡 Suppose your app ensures every profile must have a linked user_id from the users table. Consistency makes sure this rule is never broken — if a profile is created, the related user must exist.

🔒 I - Isolation

Transactions don’t interfere with each other; each feels like it's running alone.

💡 While Alice is signing up, Bob is updating his profile. Isolation ensures these actions don’t clash — Bob doesn’t see Alice’s half-complete signup, and vice versa.

💾 D - Durability

Once committed, the transaction stays committed — even if the system crashes.

💡 After Alice completes her signup, even if the server crashes right after, the new entries in users, profile, and products remain safe and saved. That's Durability.

✅ So next time you're working with databases, remember:

ACID = Trustworthy Transactions 💡

They silently keep your app stable, safe, and smart.

🏛️ 5 Pillars of SOLID

Sajidur Rahman Shajib — Fri, 06 Jun 2025 16:10:16 +0000

When it comes to writing clean and maintainable code, the SOLID principles are essential tools every developer should know. But here’s the truth: it's not just about memorizing five fancy terms — it's about recognizing when and how to apply them in real code. You don’t need to recite the definitions — you need to practice them.
The more you apply these principles, the more they become second nature, improving your design decisions over time. Keep this guide handy, and focus on using SOLID whenever you see the opportunity.

Letter	Principle Name	Abbreviation	Key Idea
S	Single Responsibility Principle	SRP	One class = One responsibility
O	Open/Closed Principle	OCP	Open to extension, closed to modification
L	Liskov Substitution Principle	LSP	Subtypes must be substitutable for base types
I	Interface Segregation Principle	ISP	No forcing of unused methods; favor small, focused interfaces
D	Dependency Inversion Principle	DIP	Depend on abstractions, not concrete implementations

🧱 S — Single Responsibility Principle (SRP)

✅ A class should have only one reason to change. Each class should handle a single part of the functionality.

🔥 Bad Example:

class UserManager:
    def add_user(self, user):
        # Add user to database
        pass

    def send_email(self, user, message):
        # Send welcome email
        pass

✅ Good Example:

class UserManager:
    def add_user(self, user):
        # Add user to database
        pass

class EmailService:
    def send_email(self, user, message):
        # Send email
        pass

🎯 When & Why:

Use SRP to make your code easier to understand, test, and modify. Changes in one responsibility won't break others.

🧱 O — Open/Closed Principle (OCP)

✅ Software should be open for extension but closed for modification.

🔥 Bad Example:

class Discount:
    def get_discount(self, customer_type):
        if customer_type == "regular":
            return 0.1
        elif customer_type == "vip":
            return 0.2

✅ Good Example:

class Discount:
    def get_discount(self):
        return 0.0

class RegularDiscount(Discount):
    def get_discount(self):
        return 0.1

class VIPDiscount(Discount):
    def get_discount(self):
        return 0.2

🎯 When & Why:

Use it when you expect requirements to evolve. This allows you to add new behavior with new classes without touching existing tested code.

🧱 L — Liskov Substitution Principle (LSP)

✅ Subclasses should be replaceable for their parent classes without altering program behavior.

🔥 Bad Example:

class Bird:
    def fly(self):
        print("Flying")

class Penguin(Bird):
    def fly(self):
        raise Exception("Penguins can't fly")

✅ Good Example:

class Bird:
    pass

class FlyingBird(Bird):
    def fly(self):
        print("Flying")

class Penguin(Bird):
    def swim(self):
        print("Swimming")

🎯 When & Why:

The Liskov Substitution Principle (LSP) applies when using inheritance. It ensures that a subclass can stand in for its parent class without breaking the program.

🧱 I — Interface Segregation Principle (ISP)

✅ Clients should not be forced to depend on methods they do not use.

🔥 Bad Example:

class Machine:
    def print(self): pass
    def scan(self): pass
    def fax(self): pass

class OldPrinter(Machine):
    def print(self): pass
    def scan(self): raise NotImplementedError()
    def fax(self): raise NotImplementedError()

✅ Good Example:

class Printer:
    def print(self): pass

class Scanner:
    def scan(self): pass

class Fax:
    def fax(self): pass

class OldPrinter(Printer):
    def print(self): pass

🎯 When & Why:

Use ISP to keep interfaces lean and focused. This avoids forcing classes to implement irrelevant functionality.

D — Dependency Inversion Principle (DIP)

✅ High-level modules should depend on abstractions, not on low-level modules.

🔥 Bad Example:

class MySQLDatabase:
    def connect(self):
        pass

class DataService:
    def __init__(self):
        self.db = MySQLDatabase()

✅ Good Example:

class Database:
    def connect(self):
        pass

class MySQLDatabase(Database):
    def connect(self):
        pass

class DataService:
    def __init__(self, db: Database):
        self.db = db

🎯 When & Why:

Use DIP to make your code more testable and flexible. It allows you to swap out implementations (e.g., use a mock DB during tests).

✅ Conclusion

The SOLID principles are timeless guidelines for writing clean, modular, and maintainable object-oriented code. By following:

SRP — keep responsibilities focused,
OCP — allow easy feature expansion,
LSP — ensure consistent behavior in subclasses,
ISP — build focused and usable interfaces,
DIP — depend on abstractions for flexibility,

you create software that is easier to test, scale, and adapt to change. Applying SOLID isn't about rigid rules — it's about writing thoughtful, future-proof code.

🧵 Thread vs Process in a nutshell

Sajidur Rahman Shajib — Thu, 05 Jun 2025 01:33:46 +0000

Understanding the difference between a thread and a process is fundamental to building scalable and efficient systems.

🔸 What is a Process?

A process is an independent program in execution.
It has its own memory space, including code, data, and system resources.
Starting an application (like a browser or server) creates a new process.

🔸 What is a Thread?

A thread is a smaller unit of execution within a process.
All threads in a process share the same memory space and resources, but each has its own call stack and program counter.

🧠 Analogy

Concept	Analogy
Process	A house
Thread	People living in the house
Shared memory	Rooms and furniture (shared by all)
Stack	Each person's backpack (private)

🧪 Real-World Example: Web Browser

Process: Running the Chrome browser.
Threads:
- One for the user interface,
- One for each tab,
- One for rendering,
- One for background tasks.

📊 Key Differences

Feature	Process	Thread
Memory	Has its own memory space	Shares memory with other threads
Overhead	Higher (more OS resources)	Lower (lightweight)
Communication	Requires IPC	Can use shared memory
Fault Isolation	Crash in one doesn’t affect others	Crash in one can crash the whole process
Creation Time	Slower	Faster

🔧 Why It Matters in System Design

Threads enable concurrency, improving responsiveness and throughput.
Processes provide isolation, which is safer for unstable or critical tasks.
Choose based on:
- Speed vs. Safety
- Available memory/CPU
- Need to share or isolate data

Understanding threads and processes helps you make better choices when designing everything from web servers to distributed systems.

🛠️ Functional and Non-Functional Requirements: Explained

Sajidur Rahman Shajib — Wed, 28 May 2025 19:42:06 +0000

When building a software system, requirements are usually classified into two main categories:

🛠️ Functional Requirements

Definition: Functional requirements specify what the system should do. They describe the core features, functions, and behaviors of the system.

Examples:

A user can register with their email and password.
The system should send a confirmation email after registration.
The admin can delete user accounts.
The search bar should return results based on keywords.

These are user-facing behaviors or operations that define how the system reacts to inputs.

🧱 Non-Functional Requirements

Definition: Non-functional requirements describe how the system performs under certain conditions. They are about quality attributes like performance, security, reliability, usability, etc.

Examples:

The system should load the dashboard within 2 seconds (Performance).
The system must support up to 10,000 concurrent users (Scalability).
All user data should be encrypted in transit and at rest (Security).
The app should have 99.9% uptime (Reliability).
The UI should be mobile-friendly and accessible (Usability).

These are not directly related to a specific function but rather to the overall system behavior.

🎯 Key Differences

Feature	Functional Requirements	Non-Functional Requirements
Focus	What the system should do	How the system should perform
Examples	Login, search, upload image	Performance, security, usability
Direct User Interaction	Yes	Often indirectly noticed
Measurable By	Pass/fail test cases	Metrics (e.g., response time, uptime)
Type of Requirement	Business logic/features	System attributes or quality factors

✅ Conclusion

Functional requirements define what a system should do, while non-functional requirements define how well it should perform. Both are crucial for delivering a complete and reliable software product.

🧠 Understanding HLD and LLD in System Design: A Developer's Guide

Sajidur Rahman Shajib — Wed, 28 May 2025 19:16:07 +0000

In the world of software engineering, designing systems that are scalable, maintainable, and robust is just as important as writing clean code. That’s where System Design comes in — and within system design, two foundational concepts stand out: High-Level Design (HLD) and Low-Level Design (LLD).

🧩 What is High-Level Design (HLD)?

High-Level Design is the architectural blueprint of a system. It focuses on what the system should do and how major components interact with each other.

🧱 Key Characteristics:

Describes the overall architecture
Focuses on major modules and data flow
Identifies external interfaces
Helps in choosing the tech stack
Think in terms of services, databases, queues, APIs

🗂️ Typical Artifacts:

System architecture diagram
Component diagrams
ER diagrams (basic database design)
Deployment diagrams (cloud setup, containerization)

🔍 Example:
In an e-commerce system, HLD would define separate services for:

User Authentication
Product Catalog
Order Management
Payment Processing

It would also define how these services interact, and what technologies (e.g., PostgreSQL, Redis, Kafka) will be used.

🔧 What is Low-Level Design (LLD)?

Low-Level Design dives into the implementation details. It defines how each module or component will work internally.

⚙️ Key Characteristics:

Describes class structures, methods, and relationships
Defines database schema in detail (tables, indexes, keys)
Specifies API request/response formats
Documents business logic and algorithms
Highlights design patterns (e.g., Singleton, Strategy)

🗂️ Typical Artifacts:

Class diagrams (UML)
Sequence diagrams
Detailed database schema
Pseudocode or function definitions

🔍 Example:

For the Order Management service, LLD would define:
A OrderService class with methods like createOrder(), cancelOrder()
DB tables: orders, order_items, with constraints
Use of design patterns (e.g., Repository for DB access)
Detailed API contract: POST /orders with request/response structure

🆚 HLD vs LLD – Key Differences

Feature	HLD	LLD
Level of Detail	Abstract / Architectural	Detailed / Code-level
Focus	What the system does & interacts with	How the system works internally
Audience	Architects, leads, stakeholders	Developers and implementers
Artifacts	Component diagrams, tech stack	Class diagrams, DB schema, APIs
Timing	Early in design phase	Right before development starts

🧠 Why Both Are Important

HLD helps align the vision of the system across teams and stakeholders.
LLD ensures developers have a clear path to start building the system.
Together, they bridge the gap from idea to implementation.

🏁 Conclusion
Whether you’re preparing for a system design interview or planning a real-world application, understanding both HLD and LLD is crucial. Start with the big picture (HLD), then dive deep into the building blocks (LLD).

📌 Pro Tip: Always validate your HLD before jumping into LLD. A shaky foundation can break the entire system!

💬 What’s your experience with HLD and LLD?
Have you worked on a project where skipping one of them caused problems later?
Let’s discuss in the comments 👇

DEV Community: Sajidur Rahman Shajib

🔄 Push vs Pull Architecture: What’s the Real Difference?

📤 What is Push Architecture?

✅ Pros:

❌ Cons:

📥 What is Pull Architecture?

✅ Pros:

❌ Cons:

👩‍💻 Alice’s Story: Choosing Between Push and Pull

1. 🔔 Real-Time Notifications (Push)

2. 📊 Weekly Reports Dashboard (Pull)

🧮 Push vs Pull: Head-to-Head

🧠 Conclusion: Which One Should You Use?

🌐 Proxy vs Reverse Proxy – Explained Simply with Alice 🧠

🔍 What Is a Proxy?

🔁 What Is a Reverse Proxy?

🧵 The Story: Alice and the Library 📚

Scene 1: Alice Uses a Proxy

Scene 2: Alice Builds a Website

💡 Practical Use Cases

✅ Proxy (Forward Proxy)

✅ Reverse Proxy

🚀 Summary

🧩 When to Use NoSQL and SQL?

🧠 What is SQL?

🌐 What is NoSQL?

📌 When to Use SQL

📌 When to Use NoSQL

⚖️ SQL vs NoSQL — Side-by-Side

💡 Final Tip

🧠 Understanding the CAP Theorem – Through Alice’s Distributed Adventure 🚀

📚 What is the CAP Theorem?

🧵 Alice and the CAP Dilemma: A Distributed Tale

🔧 Round 1: The Ideal World

⚖️ Option 1: Consistency + Partition Tolerance (CP)

⚡ Option 2: Availability + Partition Tolerance (AP)

✅ Option 3: Consistency + Availability (CA)

🧠 What Did Alice Learn?

🎯 Final Thought

🚀 A Better Way to Seed Data Using SQLAlchemy (Async-friendly)

✉️ Conclusion:

🐍 Don't Need to Create requirements.txt and .venv Manually [UV]

🏁 First install uv

🔧 uv init: Instant Project Setup

➕ uv add: Add Dependencies Instantly

🚀 uv run: Run with Environment

🔄 After Clone/Pull a UV based project

📚 Want More?

🧠 What are Pages (in OS/memory)?

🧪 Understanding the ACID Properties in Databases

🔍 What is ACID?

📖 A Short Story to Explain ACID

🧩 A - Atomicity

🛡️ C - Consistency

🔒 I - Isolation

💾 D - Durability

🏛️ 5 Pillars of SOLID

🧱 S — Single Responsibility Principle (SRP)

🔥 Bad Example:

✅ Good Example:

🎯 When & Why:

🧱 O — Open/Closed Principle (OCP)

🔥 Bad Example:

✅ Good Example:

🎯 When & Why:

🧱 L — Liskov Substitution Principle (LSP)

🔥 Bad Example:

✅ Good Example:

🎯 When & Why:

🧱 I — Interface Segregation Principle (ISP)

🔥 Bad Example:

✅ Good Example:

🎯 When & Why:

D — Dependency Inversion Principle (DIP)

🔥 Bad Example:

✅ Good Example:

🎯 When & Why:

✅ Conclusion

🧵 Thread vs Process in a nutshell

🔸 What is a Process?

🏁 First install `uv`

🔧 `uv init`: Instant Project Setup