Understanding system design through real-world examples is one of the best ways to strengthen your architecture skills.
In this post, weβll explore three popular system design case studies β each focusing on scalability, component design, and architectural choices.
Case Study 1: Designing a Parking Lot System
πΉ Problem Statement
You are tasked with building a Parking Lot Management System from scratch.
Currently, no IT system exists, and the solution must handle up to 1 million daily active users (DAU).
πΉ Client Platforms
- Web Application
- Mobile Applications (iOS & Android)
- Desktop app not required
Key Features
- List countries with available parking locations
- List cities for a selected country
- List areas or locations within a city
- List buildings for a given location
- List floors for each building
- Display available parking spaces per floor
- Show parking space details
- User signup & login
- User profile & settings
- Book, release, or cancel parking spaces
- Make secure payments
Data Storage Strategy
- RDBMS (Relational Database) β for structured data such as parking space browsing
- NoSQL Database β for user profiles, bookings, and other flexible data
Network and Integrations
- Protocol: HTTPS for all client-server communication
- Third-party Integrations:
- Push Notifications for reminders and alerts
- Payment Gateway for online transactions
- Encryption: Sensitive user data in NoSQL is encrypted
- CDN: Used to serve location-specific data to reduce latency
Service Architecture
- Monolithic Services β For user management and settings
- Microservices β For browsing and managing parking spaces
- Load Balancer β Ensures high availability for parking-space microservices
Requirement Discovery
Before design, clarify requirements such as:
- Can drivers view real-time parking availability?
- How are multi-level or open parking lots represented?
- Do we support multiple entrances/exits?
- Are there dynamic fare models based on duration or vehicle type?
Entity (Class/Component) Design
Key Entities:
- Vehicle (Car, Bus, Truck)
- ParkingSpot (Small, Medium, Large)
- ParkingBuilding, ParkingFloor, ParkingLocation, ParkingArea, ParkingCity, ParkingState
- ParkingFare, ParkingOperator, ParkingAdmin, ParkingVehicleDriver
Data Generation:
ParkingVehicleDriverprovides registration dataParkingAdminsets up the parking lot structure (buildings, floors, spaces, etc.)
π¬ Case Study 2: Designing WhatsApp (Chat Application)
πΉ Client Platforms
- Native Mobile Apps (iOS, Android)
- Web Application
- Desktop not in scope
π§© Core Features
- One-to-One Messaging (real-time via WebSocket)
- Group Messaging (multi-user via WebSocket)
- User signup, login, settings, and profile management
- Chat history and message status (sent/delivered/read)
- Presence status tracking
ποΈ Data Storage
- Message Data: Stored in NoSQL (scalable and flexible)
- User Data: Stored in RDBMS (structured)
- Chat Retention: 1 month
- CDN: Used for serving media files efficiently (images, videos, voice notes)
π Security Design
- All messages are end-to-end encrypted
- Only sender and receiver can read messages; servers cannot
- Each user pair has a unique secret key stored securely in the database
- If user A has 100 contacts, 100 secret keys exist for encryption/decryption
β‘ Data Types
- Text: Up to 10,000 characters
- Files (Audio/Video/Image): Up to 100 MB each
π¬ Case Study 3: Designing Facebook Messenger
πΉ Key Difference from WhatsApp
Unlike WhatsApp (client-initiated requests), Facebook Messenger supports true real-time bi-directional communication, allowing both server and client to initiate data exchange.
π§ Persistent Connection Methods
- Long Polling β Outdated, resource-heavy (not used)
- WebSocket β Best approach for persistent sessions
- BOSH (Bidirectional-streams over Synchronous HTTP) β Legacy alternative
βοΈ Architecture Components
- Sticky Sessions: WebSocket maintains a persistent connection with the same server
- Redis: Used as a distributed cache to store real-time session data in memory for high-speed access
π§© Additional Concepts
ποΈ Layer vs Tier
- Tier: Physical separation of systems (e.g., client, server, database)
- Layer: Logical separation (e.g., UI layer, business logic layer, data layer)
π§ Key Takeaways
- Use microservices for scalability and modularity.
- Apply NoSQL for unstructured or flexible data models.
- WebSockets are ideal for real-time systems.
- CDNs significantly reduce latency for media-heavy apps.
- Always prioritize encryption, especially in communication systems.
π Summary
| Case Study | Focus Area | Key Technologies |
|---|---|---|
| Parking Lot System | Scalability & Multi-layered system | RDBMS, NoSQL, CDN, HTTPS |
| Secure messaging & real-time communication | WebSocket, NoSQL, Encryption | |
| Facebook Messenger | Bi-directional communication & caching | WebSocket, Redis, Sticky Sessions |
β Final Thoughts
System design is not about tools β itβs about trade-offs, scalability, and maintainability.
Whether youβre designing a parking system or a global chat platform, the same principles apply:
define the problem clearly, choose the right architecture, and design for growth.
