Airline Reservation System
- Requirements
- Search available Flights for source, destination & date
- Show price list, time, Choose flight, seats and select one.
- Payment and Notification system
- DataModel
- FlightManagement
- Airlines
- Flights
- SeatsTemplate
- Airports
- Flight(FlightNumber, From, To, duration)
- Flight_Seat_Template(Seat, class)
- FlightSchedules(date, time, gate, status)
- FlightSeatAllocations
- FlightReservation
- Customer(name, email, mobile)
- Reservation(reservationNumber, #seats, flight, status, Payment mode, Pay details)
- FlightSeatAllocations(customername, age, price)
- Payment & Notifications
Movie Reservation System
- Requirements
- Movie Info
- Search by movie name, Theater name, city name
- Select Movie & Reserve tickets
- Payment & Notifications
- Comments, Rating
- Offers?
- REST API
- GET ListMovies(City, TheaterName, datetime)
- POST SeatBooking(MovieId, showId, SeatsToBeReserved)
- DataModel
- Movie
- MovieList
- Cities
- Theaters
- Screens
- ScreenSeatTemplate
- Shows(for one screen & Movie combination, date, timing)
- ShowSeatAllocations
- Ticket Reservation
- Users
- Reservation
- SeatAllocations
- Payments & Notifications
- NOSQL tables
- Comments, ratings, movieinfo, trailers, artists, cast, reviews, analytics
- HighLevelDesign
- User -> LoadBalancer -> appln server ->
Applicaiton Design
- CDN for images and videos
- LogStash & ElasticSearch for Searching. Kibana dashboard
- NoSQL for storing movie infor, comments & likes(ever increasing)
- Have replication factor for backups
- rdbms for reservation system(fixed data and acid properies).
- Have slaves for reading & Master for read/write
- Cache all Movie, Seat information(Memcache, Redis) from both NoSQL & rdbms
- Message queue for notifications(Rabbit MQ)
- Recommendation engine
- Hadoop
- Trends
- Kafka to feed data into spark
- Spark or Storm latest trends, fraud detection and mitigation strategies
Handling Concurrency
E-commerse
- VendorManagement
- Home page & Search
- Recommendation systems
- Wishlist & checkout
- Orderprocessing
- Payment and Notification
Online Food Ordering System
- Requirements
- Search by Restaurants & food
- Add to card and order food
- Payment & notifications
- Flow
- Setup
- Customer to signup and create account
- Restaurant to register
- App to track customer location and show nearby restaurants
- Customers can search based on Restaurant names / items
- Order processing
- Customer to select items from one specific restaurant only
- Payment thru pay gateway
- Restaurant gets notification
- Order fulfilment
- Restaurant sends notification of food prepared
- Delivery boy around same location accepts the request
- User track delivery boy location
- Notification when Order delivered to customer
- Entities
- Customer account
- Address(lat, long, pincode)
- Restaurants regitration (name, location, Geo location)
- Menus(drink, veg, non-veg)
- Items
- Order
- items
- DeliveryBoy
- MicroServices involved
- Ordering
- Restaurant Search service(Elastic Search) - supports geodistancequery
- Restaurant profile service
- Order fulfillment service
- Dispatcher service
Stock Brokerage System
- User Management
- User
- Watchlist
- StockHoldings
- StockManagement
- List of stocks
- ListOfOrders
- Payment
- Notifications
- Design Patterns
- Observer Design pattern
Facebook Feeds
- Requirement
- Append new post as they arrive
- Feed may contain image/video/text
- New feed must be generated based on users followed
- scalable system
- Given billions of users use the system, let us focus on backend
- Database should no NO-SQL(Cassandra, MongoDB)
- Datamodel
- User
- Friend
- FeedItem(feeditemid, userid, content, location)
- Media(MediaID, type, description, location)
- FeedMedia(feeditemid, MediaID)
- Offline generation of news feed
- background job/server generates and push to cache
- Cache will be like UserId -> LinkedHashMap<FeedItem> feeditems; lastupdatetime;
- FeednotificationService
- Pull
- Push
TinyURL
- Requirement
- Unique 7 leters alias using 72 letters(A-Z a-z 0-9).
- scalable system
- Convert long url into unique decimal value using md5 hashin
- md5 hash value -> convert to Binary -> take first 45bits -> convert to decimal number-> base62 approach -> use hashmap to convert 7 decimal reminders to 7 chars
- Base 62 approach to convert any decimal to 7 chars
- Datamodel
- User
- URL(
- System Design
- User -> Load balance -> appln server -> url generating service -> DB
- Requirement
- Upload videos,
- Share and View videos
- Search on titles
- Add and view comment
- Likes/dislikes & total view
- Rest apis
- Upload, Search, Stream
- Highlevel design
- Client -> webserver -> appln server -> processing Queue -> encoder to encode into multiple formats -> Thumbnail ->
- Database
- UserDB
- MetadataDB
- meta data for video
- Videos stored in DFS (distributed file system)
- DB schema
- Video
- Comment
- User
- Lowleve details
- Thumbnails in Bigtable by google
- Videos -> haddop distributed file sytem
- Sharding
- done on video id rather than user id
Whats app/Facebook Messger
- Requirements
- Support one-one conversation
- Offline/online status
- Chat history
- Non-Functional Requirements
- Low latency
- High availability
- Database design
- Users
- UserConversation
- Highlevel Design
- Chat server say can hold 20K connections. There will be clusters of chat servers
- UserA sends message. It goes to Chat server which is assigned to user
- Chat server stores the message to DB an forwards it to another chat server where receipent is assigned.
- Use HBASE(Wide column database)
- Chat server maintains hashmap of connected users HashMap<user, connection>
- Long Polling technique
Twitter/Instagram
- Requirements
- Post new tweets
- Follow others
- Post photos/Videos
- Timeline
- Non-Functional Requirements
- Low latency
- High availability
- Rest apis
- Post Tweet()
- GET Tweets()
- HLD
- Read Heavy
- Client -> Loadbalancer -> appserver -> Aggregator -> db shards for text & filesystem for photos.(Hadoop distributed file sytem) also cache
- Database design- NoSQL (Mongo OR Cassandra)
- MySQL
- User() -> Data is limited
- NoSQL(Mongo or Cassandra) -> ever growing data
- tweet(tweetid, userid, content, location)
- Friends()
- Database Partitioning (Sharding)
- ByUserID -> May had disadvantage when Celebrity tweets due to many followers
- TweetId-> Use Cache to overcome the disadvantage of few distributed tweets of a user
Deck Of Cards
- 4 suits - Diamond, spade, heart, club
Zoom Car(Car Renting
- Consumer
- Vehicle
- VehicleInventory
- VehicleReservation
- CarRentalLocations
Online Shopping
- Search
- Buy
- Payment
- Notifications
Design Hit Counter
- Queue based approach-> Cost is O(n)
- Array based approach ->
Uber
- Requirements
- Customer
- Customer can request a ride
- After booking customer should be able to see all available drivers
- Customer can see driver location
- Driver
- Can see customer location
- Upon reaching destination, driver marks the trip as complete to become available for others
- Quad Tree(A node will have 4 child nodes)
- World map divided into small grids in the specific range of latitude & longitude
- Start with one node that represents whole world
- Since it has more than 500M locations, break it into 4 nodes.
- Repeat the process until there are no node left with more than 500 locations
- Hashmap as cache and copy to quad tree once a min
- Notification Server -> works on pub-sub model
- When user requests for ride, system subscribes in notification server.
- Notification server will communicate with Quad server and store location of user in quad tree
- Notification server will communicate to Driver as well.
- Notification server will then communicate driver location to user
- LLD
- User -> find a ride-> quad server -> quad tree
- driver -> update location -> notification server -> hashMap
- User-> driver location -> notification server -> hashMap
Gmail
- User Service
- Mail Service
- Authentication service
Instagram(Photo Sharing Service)
- Requirements
- Upload/download/view photo
- Search based on photo title
- Follow other users
- Feed
- DB Schema/Data flow
- User(userid, mail, dob, creation_time)
- UserPosts(id, userid, date, type, location)
- UserFollow(id,
- Use nosql as it is scalable(Cassandra, MongoDB)
- epoch time -> everything represented as secs
- Sharding
- Technique to breakup the huge database into smaller parts
- memcache/Redis
- appln server -> Load balancer -> Cache1..N
- Disadvantage
- Rehashing when more cache servers are added/deleted
- Consistent hashing
- No need to do modulus with count of servers
- Total set of values are mapped into Hash ring
- Hash ring stores key of all values
- when a value is looked up, hashing is performed. It finds nearest server to it in clockwise direction.
- master/slave architecture for backups
- Configuration Manager
- zookeeper
- User -> upload file -> appln server -> cloud storage
- Metadata DB -> (chunk hash, file, user, device, workspace ID)
- Which chunk stores which part
- HLD
- Client -> block server -> cloud storage
- Client -> synchronization server -> Metadata DB
- DLD
- Client -> split the files into smaller pieces of chunks
- Maintain workspace in client appln
- Take care of offline clients
- sending notification of any modification in local client machine
Google Maps
- Influencers
- Weather
- Traffic
- Road
- compute modified route and distance when user changes direction
- Quad Tree
- Loosely coupled
- Realtime analytics
- size of architecture
- Helps in debugging
- keep sequence of events
- Mediator component take event from event queue and partitions to different processing units as per the design
- EDA model is almost same as Pub-Sub model
-
Design Pattern
- Observer Design pattern
- This is also called as Publish Subsceription design pattern
- Youtube Channel or Facebook groups
- All the subsribers/group members will get notification where channel will push the same.
- Chain Of Responsibility
- Used for loose coupling.
- Handlers in chain will decide themselves who will serve the request
- Request -> Handler1-> Handler2->Handler3
- Eg
- Multilevel secutity layer
- ATM cash withdrawl
- Logger system
- Error, Debug, info logger
- Abstract Class Logger
- Infoclass, DebugClass, ErrorClass
- Each object will have instance of next in chain object and invokes it at the end.
