HLD and LLD

একটি বহুতল ভবন বানাতে দুই ধরনের নকশা লাগে:

• স্থপতির মূল নকশা: কয়টি তলা, কোথায় লিফট, ভিত কেমন, বিদ্যুৎ ও পানির মূল লাইন কোন পথে যাবে।

• প্রকৌশলীর বিস্তারিত নকশা: প্রতিটি ফ্লোরের তারের গেজ, পাইপের ব্যাস, বিমের রড কত মোটা, সুইচ বোর্ড কোথায়।

প্রথমটি ছাড়া দ্বিতীয়টি অর্থহীন, আর দ্বিতীয়টি ছাড়া প্রথমটি বাস্তবে দাঁড়ায় না। সফটওয়্যারে এই দুই নকশাই High-Level Design (HLD) ও Low-Level Design (LLD)।

এক লাইনে: HLD উত্তর দেয় "কী কী থাকবে এবং কীভাবে যুক্ত হবে?", আর LLD উত্তর দেয় "প্রতিটি অংশ ভেতরে কীভাবে কাজ করবে?"

High-Level Design (HLD)

এখানে কোড বা ইন্টারনাল লজিকের চিন্তা করা হয় না, বরং সিস্টেমের নন-ফাংশনাল রিকোয়ারমেন্টস (Non-Functional Requirements - NFR) যেমন: স্কেলেবিলিটি, হাই-অ্যাভেইলেবিলিটি, লেটেন্সি এবং সিকিউরিটি কীভাবে অর্জিত হবে, তার একটি আর্কিটেকচারাল রূপরেখা তৈরি করা হয়।

HLD কী নির্ধারণ করে?

HLD হলো সিস্টেমের ব্লুপ্রিন্ট। এখানে কোড নিয়ে ভাবা হয় না, ভাবা হয় কম্পোনেন্ট, তাদের দায়িত্ব ও পারস্পরিক সম্পর্ক নিয়ে।

এইচএলডি (HLD) এর প্রধান ৭টি Steps:

High-Level Design (HLD) তৈরি করা মূলত একটি স্ট্রাকচার্ড প্রবলেম-সলভিং প্রক্রিয়া। তুমি যখন একদম শূন্য থেকে একটি ডিস্ট্রিবিউটেড সিস্টেম দাঁড় করাবে, তখন ধাপে ধাপে একটি সুনির্দিষ্ট ফ্রেমওয়ার্ক অনুসরণ করতে হয়।

১. Requirement Clarification (রিকোয়ারমেন্ট অ্যানালাইসিস)

যেকোনো সিস্টেম ডিজাইনের প্রথম কাজ হলো প্রজেক্টের স্কোপ বা পরিধি নির্দিষ্ট করা। একে দুটি ভাগে ভাগ করা যায়:

• Functional Requirements: সিস্টেমটি আসলে কী করবে? (যেমন: ইউজার সাইন-আপ করতে পারবে, ছবি আপলোড করতে পারবে, প্রোডাক্ট সার্চ করতে পারবে)।

• Non-Functional Requirements (NFR): সিস্টেমের পারফরম্যান্স কেমন হবে? এখানে স্কেলেবিলিটি, লেটেন্সি, থ্রুপুট এবং অ্যাভেইলেবিলিটি নির্ধারণ করা হয়। এখানেই CAP Theorem-এর ধারণা কাজে লাগিয়ে সিদ্ধান্ত নিতে হয় তুমি Consistency-কে বেশি গুরুত্ব দেবে নাকি Availability-কে।

২. Capacity Estimation (ক্যাপাসিটি এস্টিমেশন)

সিস্টেমের স্কেল বুঝতে Back-of-the-envelope calculation করা হয়। এর মাধ্যমে ইনফ্রাস্ট্রাকচারের সাইজ সম্পর্কে আগে থেকেই পরিষ্কার ধারণা পাওয়া যায়:

• Traffic Estimates: প্রতি সেকেন্ডে কতগুলো রিকোয়েস্ট (RPS) আসবে? সিস্টেমটি কি Read-heavy নাকি Write-heavy?

• Storage Estimates: আগামী ৩ বা ৫ বছরে ডেটাবেসে কী পরিমাণ ডেটা জমবে?

• Bandwidth Estimates: সিস্টেমে ইনকামিং এবং আউটগোয়িং নেটওয়ার্ক ট্রাফিকের পরিমাণ কত হবে?

৩. System Interface / API Design (এপিআই ডিজাইন)

সিস্টেমের কোর ফিচারগুলো কীভাবে ক্লায়েন্ট এবং সার্ভারের মধ্যে ডেটা আদান-প্রদান করবে, তার একটি ব্লুপ্রিন্ট তৈরি করা হয়।

• RESTful API, gRPC নাকি GraphQL ব্যবহার করা হবে তা নির্ধারণ করা।

• কোর এপিআইগুলোর স্ট্রাকচার এবং প্যারামিটার ঠিক করা (যেমন: POST /v1/orders, GET /v1/products?category=electronics)।

৪. Data Model & Database Selection (ডেটাবেস নির্বাচন)

সিস্টেমের আর্কিটেকচারে ডেটাবেস নির্বাচন সবচেয়ে ক্রিটিক্যাল সিদ্ধান্ত। ডেটার স্ট্রাকচার এবং রিকোয়ারমেন্টের ওপর ভিত্তি করে ডেটাবেস বাছাই করতে হয়:

• স্ট্রাকচার্ড ডেটা এবং জটিল রিলেশন/ট্রানজ্যাকশনের জন্য Relational Database (যেমন: PostgreSQL, MySQL)।

• আনস্ট্রাকচার্ড ডেটা এবং হাই-স্কেলেবিলিটির জন্য NoSQL Database (যেমন: MongoDB, Cassandra)।

• ছবি, ভিডিও বা স্ট্যাটিক ফাইলের জন্য Object Storage (যেমন: AWS S3)।

৫. High-Level Architecture (প্রাথমিক আর্কিটেকচার ডিজাইন)

এই ধাপে সিস্টেমের কোর কম্পোনেন্টগুলোকে ব্লকের মাধ্যমে সাজিয়ে একটি আর্কিটেকচারাল ডায়াগ্রাম (Block Diagram) তৈরি করা হয়।

• ক্লায়েন্ট থেকে রিকোয়েস্ট কীভাবে Load Balancer এবং API Gateway হয়ে ভেতরের সার্ভিসগুলোতে পৌঁছাবে তার ফ্লোচার্ট আঁকা।

• মনোলিথিক (Monolithic) নাকি মাইক্রোসার্ভিস (Microservices) আর্কিটেকচার ব্যবহার করা হবে, তা ঠিক করা।

৬. Scaling & Bottleneck Identification (স্কেলিং ও অপটিমাইজেশন)

সিস্টেমটি বড় হলে কোথায় বটলনেক (Bottleneck) হতে পারে তা চিহ্নিত করা এবং সমাধানের আর্কিটেকচারাল ডিজাইন করা:

• Caching: ডেটাবেসের লোড কমাতে এবং রেসপন্স টাইম ফাস্ট করতে ইন-মেমোরি ক্যাশ (যেমন: Redis, Memcached) যোগ করা।

• Asynchronous Processing: ভারী বা ব্যাকগ্রাউন্ড টাস্কগুলো (যেমন: ইমেইল পাঠানো, ডেটা প্রসেস করা) মেইন থ্রেডে না করে Message Queue (যেমন: Kafka, Celery, RabbitMQ) ব্যবহার করে ব্যাকগ্রাউন্ডে পাঠিয়ে দেওয়া।

• Database Scaling: ডেটাবেসের পারফরম্যান্স বাড়াতে Read-Replica, Database Sharding বা Indexing-এর পরিকল্পনা করা।

৭. Fault Tolerance & Security (নিরাপত্তা ও ফেইলিউর হ্যান্ডলিং)

• সিস্টেমে Single Point of Failure (SPOF) থাকলে তা দূর করতে সার্ভার ও ডেটাবেসের রিডান্ডান্সি (Redundancy) যোগ করা।

• রেট লিমিটিং (Rate Limiting), অথেনটিকেশন (OAuth/JWT) এবং ডেটা এনক্রিপশনের লেয়ার ডিজাইন করা।

এই ধাপগুলো ক্রমান্বয়ে অনুসরণ করলে একটি সিস্টেমের অত্যন্ত মজবুত এবং স্কেলেবল ফাউন্ডেশন তৈরি হয়, যার ওপর ভিত্তি করে পরবর্তীতে Low-Level Design (LLD)-এর কাজ আত্মবিশ্বাসের সাথে শুরু করা যায়।

HLD এর উদাহরণ (ই-কমার্স সিস্টেম):

Client (Web/App) --> CDN (Cloudflare) --> Load Balancer (Nginx) 
                 --> API Gateway 
                 --> [ Microservices: User | Product | Cart | Order ] 
                 --> Message Broker (Kafka) 
                 --> Databases (PostgreSQL for Users, MongoDB for Products) & Cache (Redis)

Low-Level Design (LLD)

HLD যদি হয় একটি বিল্ডিংয়ের আর্কিটেকচারাল নকশা, তবে LLD হলো প্লাম্বিং, ইলেকট্রিক্যাল ওয়্যারিং এবং ইটের গাঁথুনির বিস্তারিত প্ল্যান। এখানে SOLID প্রিন্সিপাল, অবজেক্ট-ওরিয়েন্টেড ডিজাইন (OOD), ডিজাইন প্যাটার্ন (Design Patterns), এবং ক্লিন আর্কিটেকচার এর (Clean Architecture) সরাসরি প্রয়োগ ঘটে।

LLD কী নির্ধারণ করে?

HLD তে আঁকা প্রতিটি বাক্সের ভেতরে ঢুকলে যা পাওয়া যায়, তাই LLD। এখানে মূল প্রশ্ন: কোড কীভাবে সাজানো হবে, যাতে সেটি সঠিক, পরিবর্তনযোগ্য ও পরীক্ষাযোগ্য হয়?

LLD এর মূল নীতি (SOLID):

• S: Single Responsibility: একটি class-এর পরিবর্তনের কারণ একটিই হওয়া উচিত।

• O: Open/Closed: নতুন আচরণ যোগ করা যাবে পুরোনো কোড না ভেঙে।

• L: Liskov Substitution: Child class দিয়ে parent-কে প্রতিস্থাপন করলে আচরণ ঠিক থাকা চাই।

• I: Interface Segregation: বড় interface-এর চেয়ে ছোট, নির্দিষ্ট interface ভালো।

• D: Dependency Inversion: Concrete class নয়, abstraction-এর উপর নির্ভর করা।

এর সঙ্গে DRY, KISS ও Composition over Inheritance তো আছেই।

LLD এর উদাহরণ (ইউজার মডিউলের অবজেক্ট ও API ডিজাইন)

// Interface for decoupling and easier testing
public interface UserService {
    User registerUser(UserDTO userDTO);
}

// Implementation
public class UserServiceImpl implements UserService {
    private final UserRepository userRepository;
    private final PasswordEncoder passwordEncoder;

    public UserServiceImpl(UserRepository userRepository, PasswordEncoder passwordEncoder) {
        this.userRepository = userRepository;
        this.passwordEncoder = passwordEncoder;
    }
    
    @Override
    public User registerUser(UserDTO dto) {
        // Validation & Business Logic
        String hashedPwd = passwordEncoder.encode(dto.getPassword());
        User newUser = new User(dto.getName(), dto.getEmail(), hashedPwd);
        return userRepository.save(newUser);
    }
}

API Contract Design:

JSON

POST /api/v1/users/register
Content-Type: application/json

{
    "name": "Farjanul Naim",
    "email": "farjanul@example.com",
    "password": "SecurePassword123!"
}

Response: 201 Created
{
    "user_id": "uuid-1234",
    "status": "Registration successful"
}

HLD এবং LLD এর তুলনামূলক বিশ্লেষণ