Search This Blog

Friday, April 29, 2022

Design Parking Garage

 Let's discuss designing parking garage as a problem statement.

At high level what all we need to consider and think about while designing a parking garage.

Product Requirements:

  • Need to be able to reserve a parking spot and receive some kind of ticket or receipt.
  • Need to be able to pay for a parking spot.
  • System needs to have a high consistency (no two people should be able to reseve the same spot at the same time).
  • 3 types of vehicles (compact, regular and large).
  • flat rate, but different rates depending of the type of parking.

APIs:
  • Public Endpoints
    • /reserve
      • Params : garage_id, start_time, end_time
      • Returns : (spot_id, reservation_id)
    • /payment
      • Params : reservation_id
      • Note : Likely using an existing API to handle (Stripe, Square etc...)
    • /cancel
      • Params : reservation_id
  • Internal Endpoints
    • /calculate_payment
      • Params : reservation_id
    • /freespots
      • Params : garage_id, vehicle_type, time
      • Note : Smaller vehicles can fit into larger spots if necessary and therefore should be included in the overall number of spots
    • /allocate_spot
      • Params : garage_id, vehicle_type, time
    • /create_account
      • Params ; email, password, first_name, last_name
    • /login
      • Params : email, password

Data Schema:
  • Reservations
    • id : primary key
    • garage_id : foreign key
    • spot_id : foreign key
    • start: timestamp
    • end : timestamp
    • paid : boolean
  • Garage
    • id : primary key
    • zipcode : varchar
    • rate_compact : decimal
    • rate_regular : decimal
    • rate_large : decimal
  • Spots
    • id : primary key
    • garage_id : foreign key
    • vehicle_type : enum
    • status : enum
  • Users
    • id : primary key
    • email : varchar
    • password : varchar (note that this probably SHA-256 hash)
    • first_name : varchar
    • last_name : varchar
  • Vehicles
    • id : primary key
    • user_id : foreign key
    • licence : varchar



Thursday, April 28, 2022

How to start with distributed systems

 Let's discuss at high level what we need to think in terms of designing distributed system.

Taking a very common example of opening pizza shop and converting it into technical terms. Let's say we wanna open a pizza shop so what all we need to consider to run it well and successfully.

Few tips/terms used by engineers when designing systems

Vertical Scaling:

  • After opening your restaurant you started getting more orders so now you need to scale your business.
    • Optimise processes and increase throughput using the same resource. 
Preprocessing using cron jobs:
  • You want to do something beforehand which can save time during peaktime like may be preparing pizza bases etc
    • Preparing beforehand at non-peak hours.
Backup Servers:
  • What if you only have one chef and if he falls sick, your business won't run that day so you need to hire one more chef as a backup.
    • Keep backups and avoid single point of failures.
Horizontal Scaling:
  • As business is running quote, it's time to hire more chefs and do more business with more orders
    • Hire more resources
Microservice Architecture:
  • As your business expanded and you have chefs with expertise like making pizza and garlic breads so you want to route specific requests to speciality chef and diving responsibilities
    • You need to build microservice architecture to achive this use-case.
Distributed Systems:
  • Let's say there is a powercut for one day or some licence issue happens in one day, your business won't run that day so you need to have one more shop may be with small scale but your business can run well.
    • You need to design distributed system to achive the above use-case.
Load Balancing:
  • Now you have two shops so someone should be intelligent enough to decide where to route order request to get efficient result.
    • You need load balancer to achieve above use-case.
Decoupling:
  • As an example delivery agent doesn't need to know what he is delivering, it is pizza today and might be burger tomorrow if you you expand your business with other verticals down the line.
    • In technical terms, it's decoupling the system and separating out concerns so that you can handle separate systems more efficiently.
Logging and metrics calculation:
  • Let's say one day there was some faulty oven or delivery agent having fault in bike and total order rate went down so you want to log everything so you can debug at any point of time later to know the reason and act on it accordingly.
    • Analytics
    • Auditing
    • Reporting
    • Machine Learning
Extensibility:
  • As a backend engineer you don't want to reqrite all this code again and again to serve a different purpose

What we have done is taken a business scenario try to find solutions to all the problems that it came up with and then just map them into technical terms. Now if you think of these, there are solutions in themseleves for the technical counterparts of the problems.

Happy Learning !! :)

My Profile

My photo
can be reached at 09916017317