Skip to main content

Fundamentals

System Design​

System Design is the process of defining the architecture, components, modules, interfaces, and data flow of a system to meet specific requirements.

Two Levels of System Design​

High-Level Design (HLD)**​

  • Big-picture view.
  • Focuses on architecture, components, and how they interact.
  • Example: “We need a frontend (React), backend (Node.js), database (PostgreSQL), caching (Redis), and load balancing (NGINX).”

Low-Level Design (LLD)**​

  • Detailed view.
  • Focuses on class diagrams, database schema, APIs, algorithms, data structures.
  • Example: “User table has columns: id, name, email, password_hash. Passwords will be hashed using bcrypt. The API /login validates credentials and generates JWT.”

Designing a URL Shortener​

Let’s go through system design fundamentals with an example.

Step 1: Requirements

  • Functional:
    • Shorten a long URL into a small one.
    • Redirect when someone hits the short link.
  • Non-functional:
    • System should handle millions of requests per day.
    • Fast lookups (<100 ms).
    • Highly available.

Step 2: High-Level Design

  • Frontend → user enters long URL.
  • Backend (API Server) → generates short code, stores mapping.
  • Database → stores mapping (shortCode → longURL).
  • Cache → for fast lookup of popular links (Redis).
  • Load Balancer → distributes traffic across servers.
User → Load Balancer → API Servers → Database
                          ↓
                        Cache

Step 3: Low-Level Design

Database Schema:

Table: URL_Mapping
- id (primary key)
- short_code (unique)
- long_url (text)
- created_at
- expiry_date

Algorithm for Short Code:

  • Take a unique ID.
  • Convert it to Base62 (digits + letters).

API Example:

  • POST /shorten → { "long_url": "https://example.com/article/1234" }
  • Response: { "short_url": "https://short.ly/cb" }
  • GET /cb → Redirects to original link.

Step 4: Scalability & Optimization

  • Sharding DB when data grows.
  • CDN for global users.
  • Monitoring & Logging for failures.

Requirements​

When we design any system, we first figure out what the system should do and how well it should do it.

That’s exactly the difference between functional and non-functional requirements.

Functional Requirements​

These describe what the system should do — the features, behaviors, and services the system must provide. They are business-oriented and directly visible to the user.

Key Points:

  • Define functions or operations of the system.
  • Answer: What must the system do?
  • Usually written as use-cases, user stories, or API specifications.
  • If not implemented → the system is incomplete.

Examples:

  • In an E-commerce System:

    • Users can sign up, log in, and reset password.
    • Users can search for products.
    • Users can add products to cart and place orders.
    • Admin can manage inventory.

  • In a Chat Application:

    • Send/receive messages.
    • Create/join chat rooms.
    • Show online/offline status.

Explanation: These are things the system must perform to be useful. They define core functionality.

Non-Functional Requirements (NFRs)​

These describe how the system performs its functions — focusing on quality attributes like speed, reliability, security, scalability, and usability. They are system-oriented and often not visible directly to the user.

Key Points:

  • Define performance constraints, quality attributes, and standards.
  • Answer: How well must the system work?
  • Usually measured with metrics (latency, uptime, throughput, etc.).
  • If not implemented → the system may still work, but poorly (slow, insecure, unstable).

Examples:

  • In an E-commerce System:
    • The system should handle 10,000 concurrent users.
    • API response time must be <200ms for 95% of requests.
    • 99.99% system uptime.
    • PCI-DSS compliance for secure payment processing.
    • Multi-language support for international users.
  • In a Chat Application:
    • Messages should be delivered in under 1 second.
    • System should scale to 1M daily active users.
    • Should support end-to-end encryption.
    • Mobile app should use <100MB storage.
    • Explanation: These don’t add new features but define constraints and expectations that make the system usable, reliable, and scalable.

Functional vs Non-Functional​

AspectFunctional Requirements 🛠️Non-Functional Requirements ⚙️
DefinitionWhat the system should doHow the system should perform
FocusFeatures, behaviorPerformance, quality, standards
User visibilityDirectly visibleIndirect, experienced as "quality"
Example (E-commerce)Add to cart, checkoutFast checkout (<3s), 99.9% uptime
Impact if missingSystem doesn’t workSystem works but poorly/unreliable

FR and NFR of Online Banking System​

Functional Requirements:

  • User can log in using credentials.
  • User can transfer money to another account.
  • User can view transaction history.
  • Bank admin can approve loans.

Non-Functional Requirements:

  • Logins must happen within 2 seconds.
  • Transactions must be atomic (either fully succeed or fail, no partial).
  • System must be available 24/7 with 99.99% uptime.
  • Must comply with financial regulations (e.g., KYC, GDPR).

Why Important? Imagine a banking app that has functional requirements (transfer money, view balance) but no proper NFRs →

  • Transfers take 10 minutes (performance issue).
  • Sometimes app crashes during transfer (reliability issue).
  • Data not encrypted (security issue).

The system technically “works” but is unusable and unsafe.