System Design: Build a Real-World Physical Storage Application

Design, optimize, analyze

A storage space application is a platform where the space owners can connect to the customer who needs to store their goods and items for a particular period of time.

Requirements and Goals of the System

Let’s design the application with the following requirements:

Functional requirements

Space Owner:

1. Onboarding a new space, a warehouse on to the application
2. Update information about an existing space. Might want to add or modify the area.
3. See what are the booking for the particular time period.

Customer:

1. Search for space storage in a particular location with search criteria
2. Book the storage for a particular period of time. With a minimum duration of say 15 days.
3. Check the booking

Additional Requirements:

1. Space owner to provide pickup and drop service of the goods
2. Goods can be personal, business, document, household or automobiles.
3. An option to view live footage (If CCTV is installed by the space owner). This builds trust.
4. Insurance of the goods to be provided by the space owners. All app may withhold money from the space owner, completely refundable and transferred back to the space owners once the contract ends.
5. Analytics to check for which space locations and area work best.

Non-functional requirements

1. Low Latency
2. High availability
3. High consistency.

Capacity Estimation

Let’s assume there are ~500k space owners and about ~10M storage space across the globe.

This application would have less active users as the users will mostly be using the service once in a particular period of time.

System Architecture

Our application will mostly consist of three main UIs :

1. UI/APP for Space owners
2. UI/APP for customers to make bookings
3. Common UI/APP for viewing bookings

Our application will consist of the following components:

1. Load balancers: They balance the traffic onto multiple servers coming from all UIs, helping the application scale.
2. Storage Service: This service will let the space owners save their storage space details and also include blob data i.e images/videos of the place.
3. NoSql Cluster: to save the the metadata of the storage space. We can use any nosql db for this.
4. CDN: we will need CDN to distribute the information geographically

All the information will be real time updated to the customers and space owner regarding new storage uploaded for search and bookings made. For this we will use Message Queues such as Kafka or Rabbit MQ.

1. KAFKA: To provide streaming of data from producers to consumers.
2. Search Consumer: The data about new storage updated in the app will flow to search consumers which will connect to Elastic Search.
3. ELASTIC search cluster: Mainly used fast search service retrievals as well as fuzzy search.
4. Search Service: Search service will able to get the result from elastic search and provide to customer UI.
5. Booking Service: Booking services enable customers to make block a particular storage for a particular period of time. This data will flow to Kafka. Why? Because we once we book the storage space, we do not want it to show in search for that particular period of time.
6. Booking service will talk to payment service for payment related. Once payment is successful we can make booking successful in our nosql cluster.
7. Archival Service: For live bookings. This basically blocks bookings and store the data in Casandra kind of database. Can use HBase as well.
8. Notification service: To notify all users. For example, if a booking is made by the customer, then notify the space owner. Else if its canceled by the space owner then notify the customers.
9. Booking Management Service: This service will talk to the customers and space owners to view the booking. The booking comes from NoSQL clusters (saying cancel, in progress, payment failed, successful) and achieved service through Casandra db for live bookings.
10. Redis: To reduce the load on our db cluster and is used as a cache for quick retrievals.
11. Hadoop cluster: For space and booking transaction flows in and we can analyze and operate some M.L. over it.

API and Database Design

We will have primary 4 main APIs to upload and update storage:

POST /space ( to onboard new space storage)

GET /space/:id (To fetch particular storage to view information and book )

PUT /space/:id (To edit information of a particular space)

DELETE /space/:id (To delete a particular space)

For booking we will have:

POST /booking (To make a booking for particular storage at a particular time interval)

For using a database, a relational database suits this kind of business model because of its ACID guarantees.

Space Database

Space: {id, type, name, locality, dimensions, amenities, description, original_images, is_active, price_per_day}
SpaceType ENUMS: [PERSONAL, BUSINESS]
SpaceAmenities: {id, space_id, amenity_id, is_active}
SpaceLocality: {id, city_id, state_id, country_id, zipcode, is_active}

Booking Database

AvailableSpace: {space_id, date, initial_qty, available_qty > 0}
Booking: {booking_id, space_id, user_id, start_date, end_date, status, invoice_id, goods_type}
GoodsType ENUMS: [HOUSEHOLD, AUTOMOBILE, OFFICE_ITEMS]
Status ENUMS: [RESERVED, BOOKED, CANCELLED, COMPLETED]

How the API will interact from the UI to the application server and then eventually to DataBase:

POST /book with for example these parameters {booking_id, space_id, user_id, start_date, end_date}

1. Check for available space [ every Available space/ room ]
2. Insert in booking db and reduce the available_qty
3. Put in Redis with TTL (Time to Live) For example with 10mins of live bookings to reserve the booking and then it will expire. Redis will notify once the token expires. We will handle this later.
4. Put in Kafka (Message Queue)
5. Redirect to Payments. Optionally can redirect to Chat for peer to peer communication between owner and customer (Update booking status post that)

How to handle Redis Expire Token?

Redis key will eventually expire.

1. If the Redis key expires and payment then goes to success, then we can handle this in multiple ways like either reverting the payment to the user notifying him that the request expired. Or a smarter way to do it would be to check if the available storage is available then book it.
2. If Payments goes successful then we can ignore if the Redis token is expired.

Optimizations

If the payment goes successful then we can directly delete the key from Redis.

We also should Monitor the complete system on how CPU and memory are working.

Across the whole infrastructure, we need to keep an eye on how CPU usage percentage is and how memory and disc usage percentage is.

Monitoring could be done by grifana kind of a tool where we can set up alerts on a particular threshold. If any threshold is crossed, the developer will to be alerted.

This is super important for low latency and high availability.

Analytics

We can set up Kibana logs in our application and create a different type of graphs on kibana dashboard to monitor how and which storage are working best, the demand and supply in a particular area, and also what is the success and failure rate of the booking.

Based on this data, the business takes action on how and which direction the application is to focus.

Distributed Data

We can distribute our data geographically by setting up data centers in a different part of the region as space storage will mostly be set up in one particular area and not move.

So the user of region 1 says India should fetch data from the India data centre, and user from region 2 say USA, should fetch data from the US data center.

The data will have replication nodes. This is done if one of the nodes goes down, another one can take its place to retrieve information/data. The replication can also be paired with the partition of data with regions,