SOFTWARE ENGINEERING

ASSIGNMENT
NAMAN.V (17BCE7003)
Slot:E1/TE1

1. Case Study: "UBER|LYFT|GRAB|OLA System design”. Consider the any one system
design architecture and answer the following questions. (each question answer can be
max. of 500 words).

A. Understand the above system design of the App & explain the scenario?
ans: Uber’s Dispatch system acts like a real-time market platform that matches drivers with riders
using mobile phones.
So we need two services
 Supply service
 Demand service
Supply service:
• The Supply Service tracks cars using geolocation (lat and lang) Every cab which is active keep
on sending lat-long to the server every 5 sec once
• The state machines of all of the supply also kept in memory
• To track vehicles there are many attributes to model: number of seats, type of vehicle, the
presence of a car seat for children, can a wheelchair be fit, and so on.
• Allocation needs to be tracked. A vehicle, for example, may have three seats but two of those
are occupied.
Demand service:
• The Demand Service tracks the GPS location of the user when requested
• It tracks requirements of the orders like Does a rider require small car/big car or pool etc
• demand requirements must be matched against supply inventory.
Now we have supply and demand. all we need a service which matches they demand to a supply
and that service in UBER is called as DISCO
DISCO — DISPATCH optimization
This service runs on hundreds of processes.
Core requirements of the dispatch system:
 reduce extra driving.
 reduce waiting time
 lowest overall ETA
B. What is the various use cases for the selected APP & explain?
ans: Rider app:
1.Scheduled Booking
2.Real time Navigation
3.App Call / Chat
4.Wallet Payment
5.Promotion Codes
6.Stripe payment
7.User Profile
8.working history
9.Ride Request Notifications
10.Estimation fare Calculation
11.Pay by Cash Option
12.User can Invite Friends
13.Emergency Contact Sharing
14.Book a Ride with Destination
15.Favorites location Option for the Rider
Driver app:
1.Online and offline
2.User Profile
3.App Call / Chat
4.Work History
5.Ride Request Notifications
7.Real time Navigation
8.driver Payout
9.working history
10.Rating and feedback List
C. What is the software design of the LYFT/Grab App & explain?
ans: To provide the good-quality work of the taxi ordering application, not only the mobile app
interface matters, but also the "back-end" part. It is about the server application which receives user
data, processes it, sending to the certain services and apps. This back-end part actually makes the
communication between different elements of the mobile app system possible.

The architecture can be explained as the 3 levels of the system work:

  Servers;
 Applications on servers (back-end part);
 Admin panel and mobile apps (front-end part).

The communication between system elements is possible thanks to the API.

The system faces challenge when it's the high load. To cope with it successfully and show good
speed of work, the architecture should be optimized:

 Structurize well the data on server;

 Define the maximum system load;

 Choose the technologies that will help to cope with the load;

 Choose suitable servers for a location;

 Test load before launching the app.

D. What software process model can be adopted for development?

ans: The software process adopted for the development is hybrid cloud model.
E. What are the various challenges faced by UBER? (consider with respect to
Supply(cabs), demand(riders) and answer the query)
ans: New model or new face
Much of the debate around how Uber and similar apps operate comes down to a
fundamental disagreement about what sort of businesses they represent: traditional taxi and
hire-car firms claim Uber, Lyft and similar service providers are in the same business as
them and should be regulated accordingly; Uber, for its part, is very careful in its language,
referring to its product as a “ride-sharing” app, and presenting itself as a platform that
connects drivers with consumers. It just so happens that the person whose ride you are
sharing is a professional driver with a license and commercial insurance.
In October, a High Court judge in London came down on the side of Uber, ruling the
company’s app did not constitute a metering system – something only the city’s heavily
regulated black-cab drivers are allowed to operate. Nevertheless, that is unlikely to end
opposition from London’s 25,000 cabbies, who have previously blockaded various parts of
the city in protest against the firm.
Fears for safety
One criticism black-cab drivers have levelled against Uber is the supposed
untrustworthiness of its drivers. This isn’t helped by cases such as that in India, where a
woman was raped by one of the firm’s drivers, or in San Francisco, where District
Attorney George Gascon is in the process of suing the firm. Gascon claims Uber failed to
uncover the criminal backgrounds of 25 of its drivers, including one who had spent 26
years in prison for second-degree murder.
An element of trust is, of course, implicit in any transaction made in the sharing economy;
in stripping down the barriers between provider and consumer, you also remove many of
the checks, guarantees and buffers. And that cuts both ways. Joseph De Wolf Sandoval,
President of the California App-Based Drivers Association, told Business Insider: “Drivers
are subject to hostile environments and sexual harassment, assault, and being involved
with people who are potentially dangerous.” In Brisbane, two men were taken to court for
allegedly using the Uber app to lure in drivers they then beat up.
Uber is a prime example of a ‘disruptive’ start-up. By making hire cars instantly
accessible, it and its fellows have made a better deal for consumers, but they’ve also
sidestepped regulations that have been carefully built up over decades. They may not play
by the old rules, but they, as much as anybody else, need some form of protection.

 Uber was fined $67,750 after it began offering its services in Portland without
proper regulatory approval. The city and the firm eventually reached an agreement,
but not before each had publicly denounced the other.

 New York’s traditional yellow taxi firms aren’t fans of Uber, but last July the firm
was able
 to see off a bill backed by mayor Bill de Blasio that would have put a cap on the
number of vehicles it could operate in the city.

 UberPOP was suspended in France the same week two of the company’s
executives were arrested for “illicit activity”. The head of Uber France told Le
Monde the suspension was “primarily to assure the safety of Uber drivers”.

 Agents from the Netherlands’ Transport Inspectorate raided Uber’s European

headquarters twice last year as part of an investigation into whether the company
was running an
 illegal taxi service.

 Uber is being investigated for criminal negligence in India after one of its drivers
raped a passenger. The firm has introduced an SOS feature that can put riders
directly in contact with the police.

 The Chinese Ministry of Transportation has proposed new guidelines that would
mean fees, the number of cars in a fleet, and where ride-sharing firms can operate
would be decided by local authorities.
F. Differentiate Monolithic architecture and Micro service architecture. Which is best UBER
type of systems?
ans: Monolithic Architecture
 Simple to develop.
 Simple to test. For example you can implement end-to-end testing by simply launching the
application and testing the UI with Selenium.
  Simple to deploy. You just have to copy the packaged application to a server.
 Simple to scale horizontally by running multiple copies behind a load balancer.
In the early stages of the project it works well and basically most of the big and successful
applications which exist today were started as a monolith.
Drawbacks of Monolithic Architecture
 This simple approach has a limitation in size and complexity.
 Application is too large and complex to fully understand and made changes fast and
correctly.
 The size of the application can slow down the start-up time.
 You must redeploy the entire application on each update.
 Impact of a change is usually not very well understood which leads to do extensive manual
testing.
 Continuous deployment is difficult.
 Monolithic applications can also be difficult to scale when different modules have
conflicting resource requirements.
 Another problem with monolithic applications is reliability. Bug in any module (e.g.
memory leak) can potentially bring down the entire process. Moreover, since all instances
of the application are identical, that bug will impact the availability of the entire application.
 Monolithic applications has a barrier to adopting new technologies. Since changes in
frameworks or languages will affect an entire application it is extremely expensive in both
time and cost.
Microservices Architecture
The idea is to split your application into a set of smaller, interconnected services instead of building
a single monolithic application. Each microservice is a small application that has its own hexagonal
architecture consisting of business logic along with various adapters. Some microservices would
expose a REST, RPC or message-based API and most services consume APIs provided by other
services. Other microservices might implement a web UI.
The Microservice architecture pattern significantly impacts the relationship between the application
and the database. Instead of sharing a single database schema with other services, each service has
its own database schema. On the one hand, this approach is at odds with the idea of an
enterprise-wide data model. Also, it often results in duplication of some data. However, having a
database schema per service is essential if you want to benefit from microservices, because it
ensures loose coupling. Each of the services has its own database. Moreover, a service can use a
type of database that is best suited to its needs, the so-called polyglot persistence architecture.
Some APIs are also exposed to the mobile, desktop, web apps. The apps don’t, however, have
direct access to the back-end services. Instead, communication is mediated by an intermediary
known as an API Gateway. The API Gateway is responsible for tasks such as load balancing,
caching, access control, API metering, and monitoring.
Benefits of Microservices Architecture
 It tackles the problem of complexity by decomposing application into a set of manageable
services which are much faster to develop, and much easier to understand and maintain.
 It enables each service to be developed independently by a team that is focused on that
service.
 It reduces barrier of adopting new technologies since the developers are free to choose
whatever technologies make sense for their service and not bounded to the choices made at
 the start of the project.
 Microservice architecture enables each microservice to be deployed independently. As a
result, it makes continuous deployment possible for complex applications.
 Microservice architecture enables each service to be scaled independently.
Drawbacks of Microservices Architecture
 Microservices architecture adding a complexity to the project just by the fact that a
microservices application is a distributed system. You need to choose and implement an
inter-process communication mechanism based on either messaging or RPC and write code
to handle partial failure and take into account other fallacies of distributed computing.
 Microservices has the partitioned database architecture. Business transactions that update
multiple business entities in a microservices-based application need to update multiple
databases owned by different services. Using distributed transactions is usually not an
option and you end up having to use an eventual consistency based approach, which is more
challenging for developers.
 Testing a microservices application is also much more complex then in case of monolithic
web application. For a similar test for a service you would need to launch that service and
any services that it depends upon (or at least configure stubs for those services).
 It is more difficult to implement changes that span multiple services. In a monolithic
application you could simply change the corresponding modules, integrate the changes, and
deploy them in one go. In a Microservice architecture you need to carefully plan and
coordinate the rollout of changes to each of the services.
 Deploying a microservices-based application is also more complex. A monolithic
application is simply deployed on a set of identical servers behind a load balancer. In
contrast, a microservice application typically consists of a large number of services. Each
service will have multiple runtime instances. And each instance need to be configured,
deployed, scaled, and monitored. In addition, you will also need to implement a service
discovery mechanism. Manual approaches to operations cannot scale to this level of
complexity and successful deployment a microservices application requires a high level of
automation.

G. How ETA is calculated in UBER app between Rider & Cab

ans: For example,
1. A cab which is about to finish near the demand(rider) is better than allocating the
cab which is far away from the demand.
2. Sometimes revising a route of an ongoing trip because some cab near to demand
came online.
when uber started every cities data was separated by creating separated tables/DB this was
not easy
now all the cities computation happens in the same system, since the workers the DBnodes
are distributed by regions the demand request will be sent to the nearest datacenter.
Routing and Calculating ETA is important component in uber as it directly impacts ride
matching and earnings.
so it uses historical travel times to calculate ETAs
you can use AI simulated algorithms or simple Dijkstra's also to find the best route
 Also you can use Driver’s app’s GPS location data to easily predict traffic condition at any
given road as there are so many uber cars on the road which is sending GPS locations
every 4 seconds
The whole road network is modeled as a graph. Nodes represent intersections, and edges
represent road segments. The edge weights represent a metric of interest: often either the
road segment distance or the time take it takes to travel through it. Concepts such as
one-way streets, turn restrictions, turn costs, and speed limits are modeled in the graph
as well.
One simple example you can try at home is the Dijkstra’s search algorithm, which has
become the foundation for most modern routing algorithms today.
OSRM is based on contraction hierarchies. Systems based on contraction hierarchies
achieve fast performance — taking just a few milliseconds to compute a route — by
preprocessing the routing graph.

2. Case Study: Designing Instagram

Let's design a photo-sharing service like Instagram, where users can upload photos to share
them with other users. Similar Services: Flickr, Picasa Difficulty Level: Medium
Answer the following questions:
A. What is Instagram?

ans: Instagram is a social networking service which enables its users to upload and share their photos
and videos with other users. Instagram users can choose to share either publicly or privately. Anything
shared publically can be seen by any other user, whereas privately shared contents can only be
accessible by a specified set of people. Instagram also enables its users to share through many other
social networking platforms, such as Facebook, Twitter, Flickr, and Tumblr.

B. List Functional and Non functions Requirements

ans:Functional Requirements

 Users should be able to upload/download/view photos.

 Users can perform searches based on photo/video titles.

 Users can follow other users.

 The system should be able to generate and display a user’s News Feed consisting of top photos
from all the people the user follows.

Non-functional Requirements

 Our service needs to be highly available.

 The acceptable latency of the system is 200ms for News Feed generation.
  Consistency can take a hit (in the interest of availability), if a user doesn’t see a photo for a while,
it should be fine.

 The system should be highly reliable, any uploaded photo or video should never be lost.

C. Goals of the System

ans: Adding tags to photos, searching photos on tags, commenting on photos, tagging users to photos,
who to follow, suggestions, etc.

D. Identify Design Considerations

ans:The system would be read-heavy, so we will focus on building a system that can retrieve photos
quickly.

 Practically users can upload as many photos as they like. Efficient management of storage should
be a crucial factor while designing this system.

 Low latency is expected while viewing photos.

 Data should be 100% reliable. If a user uploads a photo, the system will guarantee that it will
never be lost.

E. Give example for the scenario: Capacity Estimation and Constraints in Instagram

 ans:Let’s assume we have 500M total users, with 1M daily active users.

 2M new photos every day, 23 new photos every second.

 Average photo file size => 200KB

 Total space required for 1 day of photos

2M * 200KB => 400 GB

 Total space required for 10 years:

400GB * 365 (days a year) * 10 (years) ~= 1425TB

F. Draw its High Level System Design

ans:
G. Draw its Database Schema

ans:

H. What are the different approaches for sending News Feed contents to the users?

ans:a. Partitioning based on UserID :Let’s assume we shard based on the ‘UserID’ so that we can keep all
photos of a user on the same shard. If one DB shard is 1TB, we will need four shards to store 3.7TB of
data. Let’s assume for better performance and scalability we keep 10 shards.

So we’ll find the shard number by UserID % 10 and then store the data there. To uniquely identify any
photo in our system, we can append shard number with each PhotoID.

b. Partitioning based on PhotoID: If we can generate unique PhotoIDs first and then find a shard number
through “PhotoID % 10”, the above problems will have been solved. We would not need to append
ShardID with PhotoID in this case as PhotoID will itself be unique throughout the system.

I. Data Size Estimation: • Estimate how much data will be going into each table and how much total
storage we will need for next 10 years for 500million user?

Ans: a. 42GB b.32GB c.720GB d.120GB.

ans:32GB.

3. Case Study: Google Drive| Drop Box System Design

A. Consider the features of systems and draw its System Design

ans:

B. Various challenges of the systems

ans:

 Synchronisation

 Dropbox Website going down

 Dropbox Files Missing

 Dropbox Errors

 Dropbox Failed to Uninstall

 Dropbox Not Working

 Fail to Login to Dropbox

  Constant Crashes

C. List out of the major features of the systems

 256-bit AES encryption security

 Any device accessibility

 Automatic organization and back-up

 Automatic updates

 Efficient syncing

 File sharing

 File storage

 Large file sharing

 Manually set bandwidths

 Offline access

 Online back-up and file recovery

 Preview and download

 Simple link-sharing via email, chat or text message

D. What about data scalability ? (if data size increases)

Dark launch: In August 2014, they embarked on “dark launch,” at which point they were mirroring
data between two regional locations and considered the system ready to store user data. Of course,
being Dropbox, they kept extra backups for another 6 months after this date just in case.

Launch day: February 27, 2015 was D-day. For the first time in the history of Dropbox, they began storing
and serving user files exclusively in-house. Once it validated the new infrastructure, it set an aggressive
goal of scaling the system to more than 500PB in six months.

BASE Jump: On April 30, 2015, they began the race to install additional servers in three regional locations
fast enough to keep up with the flow of data. To make this all work, they built a high-performance
network from the servers which allowed them to transfer data at a peak rate of over half a terabit per
second. Because their schedule left so little time to “open the parachute,”they called this part of the
project BASE Jump. On the hardware side, they were pushing up against the limitations of how many
racks of hardware could fit in the loading dock at one time.

Successful landing: The goal was to serve 90% of the data from in-house infrastructure by October 30,
2015. They actually hit the mark almost a month early, on October 7, 2015. The team not only delivered
on time, but also achieved this significant technical undertaking without any major service disruptions or
any loss of data.

4. Case Study: WhatsApp Messenger is a cross-platform mobile messaging app which

allows you to exchange messages without having to pay for SMS.
A. What is underlying architecture of WhatsApp?
ans:
WhatsApp uses LYME/LYCE stack, except for the Linux part that is. The co-founders opted for FreeBSD
over Linux because they know the system inside out and like its security and robustness.

So the app’s underlying architecture is this:

OS: FreeBSD

Programming language: Erlang

Virtual machine (to run Erlang): BEAM

Servers: Ejabberd, YAWS

Ejabberd server is based on a set of pluggable modules that enable features like:

 One-on-one messaging

 Store and forward (offline messages)

 Contact List and presence

 Group chat - Multi User Chat (MUC)

 Message archive Management (MAM)

 Personal event protocol (PEP) and typing indicator

 Privacy settings, simple blocking extensions

They use a customised version of XMPP - (eXtensible Messaging and Presence Protocol) which enables
message delivery. They call it FunXMPP (details on customization are in this post). WhatsApp stores
multimedia files on YAWS (Yet another web server).

Database: Mnesia

Offline database: SQLite

WhatsApp is an asynchronous IM app. It uses a client-server model for messaging. All the messages are
stored locally (on the app). They queue on the server, though, in case a recipient is offline. As soon as
delivered, the queue is deleted. A user may back them up to Google cloud.
B. What is LYCE/LYME Architecture and draw its architecture diagram.

C. How messaging server works in whatsapp?

ans: WhatsApp or most of the other messaging apps rarely work on a peer to peer basis. So it wouldn't
open a connection (from your device) to each of your friends' devices. Instead your device connects to
their server. It could then use a custom TCP protocol or maybe HTTP to communicate your messages to
the server. The server in return would dispatch them to your friends' devices. If your friend had their app
open or at least the app process running there might be a live connection to the server. WhatsApp will
use that connection to send them your messages. If their app is "offline" then they might choose to send
them a push notification instead. WhatsApp has chosen Erlang a language built for writing scalable
applications that are designed to withstand errors. Erlang uses an abstraction called the Actor model for
it's concurrency .Instead of the more traditional shared memory approach, actors communicate by
sending each other messages. Actors unlike threads are designed to be lightweight. Actors could be on
the same machine or on different machines and the message passing abstractions works for both. A
simple implementation of WhatsApp could be: Each user/device is represented as an actor. This actor is
responsible for handling the inbox of the user, how it gets serialized to disk, the messages that the user
sends and the messages that the user receives

D. Assume there are various features called user base,last seen,media,emcrypt and telephony services.
Explain how to implement Lastseen in Whatapp system design

ans: Implementation of this feature is very simple and straightforward, It is just about maintaining a
record with Client ID and Timestamp.
When we open Whatsapp in our smartphone, our application sends a pulse to server every 5 seconds,
and with every pulse last seen time is updated in the table. As the client disconnects the last seen time
exists in the record that is updated by the last pulse sent before closing the app.