Enterprise System Design - CSC337 (Interactive Edition)

1. Basic Web se Enterprise Scale tak ka Safar

CSC336 (Past)[cite: 1]

Pichlay course mein humne dekha ke basic web pages aur frontend kaise banta hai (HTML/CSS). Lekin real-world mein, jab hazaron ya millions users ek sath app use karte hain, toh basic servers crash ho jatay hain[cite: 1].

CSC337 (Future)[cite: 1]

AWT ka Maqsad: Is course mein hum enterprise-grade systems banayenge. Hum seekhein ge ke fault tolerance, caching, security, aur APIs ko real-world industry standards ke mutabiq kaise design kiya jata hai[cite: 1].

Real World Example: Sochiye ke jab Daraz par 11.11 sale lagti hai, ya Netflix par ekdam naye season ka episode release hota hai, toh karoron users ek sath request bhejte hain. Agar backend weak ho toh app down ho jati hai![cite: 1]

2. Software Architecture Kyun Zaroori Hai?

The Problem

Feature code karna aasaan hai, lekin us feature ko 1 million concurrent users ke liye zinda rakhna aur crash hone se bachana asli challenge hai.

The Solution

Architecture sirf code nahi hai, yeh trade-offs ka naam hai—yani Cost vs Performance vs Complexity ka behtareen balance.

🎮 Simulation: Load Balancer & Traffic Test

Server A

Server B

Server C

Status: System stable and running smoothly.

3. The 5 Pillars of Enterprise Full-Stack Application

Har enterprise application 5 mukhtalif layers mein divided hoti hai. Separation of concerns ki wajah se system maintainable aur massively scalable banta hai:

1. Presentation Layer: UI/UX, Mobile apps, Web browsers.
2. Application Layer: API Gateways, Routing, Business logic.
3. Business Layer: Core rules, Discounts, Validations.
4. Data Access Layer: Polyglot Databases & Caching (Redis).
5. Infrastructure Layer: Cloud, Containers, Physical networks.

4. Business Layer: Domain Understanding & Rules

Functional Requirements

What the app actually does (Features)

User cart mein item add kar sakay.
System discount voucher apply kare.
Payment gateway par transaction process ho.

Non-Functional Requirements (NFRs)

How well it performs (Quality Attributes)

Cart update hone ki latency < 200ms ho.
System peak hours mein 5000 checkouts/sec handle kare.
Strict PCI-DSS security standards follow hon.

5. Infrastructure Layer: Servers, Containers & The Cloud

Stack	On-Premise	IaaS (e.g. AWS EC2)	PaaS (e.g. Heroku)	SaaS (e.g. Google Workspace)
Applications	You Manage	You Manage	You Manage	Cloud Model Concept: Jitna upar jayenge, utna kam infrastructure manage karna parega aur control cloud provider ke paas hoga.
Data	You Manage	You Manage	Cloud Provider
Runtime	You Manage	Cloud Provider	Cloud Provider
O.S.	You Manage	Cloud Provider	Cloud Provider
Hardware	You Manage	Cloud Provider	Cloud Provider

6. Application Layer: Traffic Control & Resilience

Stateful vs Stateless Architecture

Stateful: User session server ki memory mein save hota hai (Scale karna mushkil, Single point of failure).

Stateless: Tokens (JWT) use hote hain. Har request independent hoti hai, jisay horizontal scaling aasaan ho jati hai.

Graceful Degradation (Fault Tolerance)

Example: Agar Netflix ka recommendation engine down ho jaye, toh poori app crash nahi honi chahiye. API Gateway chupkay se default trending movies ki list show kar deta hai!

7. Data Layer: Polyglot Persistence

Pehlay zamane mein sab kuch ek hi database mein rakha jata tha. Ab enterprise apps 'Polyglot Persistence' use karti hain—yani jis kaam ke liye jo database behtareen ho, wahi use kiya jaye.

SQL (Relational - PostgreSQL)

Best For: User accounts, Billing & Money transactions jahan ACID properties strict chahiye.

NoSQL (Document - MongoDB)

Best For: E-commerce product catalogs jahan items ki properties mukhtalif aur flexible hoti hain.

8. Database Scaling: Replication & Partitioning

Replication (Read-Heavy): Ek Master DB hota hai jo writes handle karta hai, aur multiple Replica DBs sirf reads handle karte hain (High Availability).
Partitioning / Sharding (Write-Heavy): Boht baray dataset ko horizontal chunks mein divide karna taa ke unlimited scale achieve ho.
Indexing: Slow queries ko fast karne ke liye index banaya jata hai, bilkul waise hi jaise kisi textbook ke end par index page hota hai.

9. The CAP Theorem: The Architect's Dilemma

Distributed systems ke mutabiq network failure (Partition Tolerance - P) lazmi hoga. Isliye aapko Consistency (C) aur Availability (A) mein se koi ek chunna parta hai.

🧪 Interactive CAP Theorem Explorer: Konsa system chunenge?

Koi ek option select kar ke iska tradeoff dekhein.

10. Architectural Evolution: Monolith se Microservices tak

Monolithic: Startups aur early-stage products ke liye best, kyunke deployment single hoti hai.
Modular Monolith: Code ke andar saaf boundaries hoti hain lekin deployment ek hi hoti hai.
Microservices: Independent teams aur massive scaling ke liye, lekin complexity bohat high hoti hai.

Rule of Thumb: Har application microservices se shuru nahi karni chahiye. Monolith tab tak best hai jab tak aapki team aur codebase manage karne ke qabil na ho jaye.

11. Microservices Principles & Bounded Contexts

Example: Food Delivery App (Database-per-Service Pattern)

User Auth Service: Uses PostgreSQL
Restaurant Catalog: Uses MongoDB

Order Processing: Uses PostgreSQL
Rider Tracking: Uses Redis (In-memory fast tracking)

Core Rule: Har microservice ka apna alag database hona chahiye. Agar saari services ek hi DB share karein, toh wo 'Distributed Monolith' ban jata hai jo sab se khatarnaak anti-pattern hai!

12. Inter-Service Communication: APIs & Queues

Synchronous (REST / gRPC)

Kahan use karein? Jab user ko screen par foran response chahiye ho (e.g. Login request, profile fetch). Yeh blocking communication hoti hai.

Asynchronous (Message Queues - Kafka / RabbitMQ)

Kahan use karein? Background tasks ke liye jahan foran response ki zaroorat nahi hoti (e.g. Order place hone ke baad email/SMS bhejna, inventory update karna).

13. Microservices: Faiday, Nuqsan aur Trade-offs

FAIDAY (Benefits)

Independent Scaling (Sirf Rider Tracking service scale karein, poori app nahi).
Technology Freedom (NodeJS for API, Python for ML).
Fault Isolation (Ek service down honay se baqi app chalti rehti hai).

NUQSAN (Challenges)

Network Latency (Data network par travel karta hai).
Complex Debugging (Distributed tracing karna mushkil hota hai).
Operational Overhead (Kubernetes aur DevOps ki sakht zaroorat parti hai).

14. The Serverless Paradigm (Scaling to Zero)

Real Scenario: Sochiye ek image resizing function jo tabhi run hota hai (aur aapko bill karta hai) jab user nayi profile picture upload kare. Jab koi upload nahi kar raha, toh server cost $0 hoti hai!

The Cold Start Issue: Jab function kaafi der tak idle rahe aur achanak request aa jaye, toh server ko wake up hone mein 1-2 seconds lag sakte hain.

15. SYNTHESIS: The Ultimate Enterprise Blueprint

Yeh hai CSC337 ka actual goal: Basic web pages se nikal kar, tamaam layers, caching, queues, aur microservices ko apas mein jor kar ek fault-tolerant aur massively scalable system design karna.

Agla Qadam (Lecture 5): Ab jabke system architecture tayar hai, agle lecture mein hum in components ke darmiyan perfect communication ke liye API Design (REST & GraphQL) seekhenge!

Lec 3 and 4