System requirements
Functional:
List functional requirements for the system (Ask interviewer if stuck)...
- Allowing drivers to reserve parking spots
- Keep track of available parking spots: The system needs to maintain real-time updates on the number of empty spots for different types of vehicles. Sometimes a rough estimation
- Record entering time: Capture and store the timestamp when a vehicle enters the parking lot to track duration.
- Identify available parking spots: Determine available spots based on the size of the vehicle upon entry.
- Handle full parking lot: Provide a message when no parking spot is available, directing the user to exit.
- Calculate parking fee: Calculate fees based on the duration a vehicle is parked in the lot.
- Accept payment: Allow drivers to make payments using various methods upon exiting the parking lot.
Non-Functional:
List non-functional requirements for the system...
- High availability: Ensure the system is operational and accessible at all times to avoid disruptions.
- Secure payment system: Implement robust security measures to protect payment transactions and user data.
- Data preservation: Store payment and vehicle entry/exit logs securely in a durable and reliable database for auditing and analysis purposes.
- Data Consistency: Ensure data consistency when multiple vehicles come in at the same time.
API design
Define what APIs are expected from the system...
enter(license: string, vehicle_size:enum) -> num_of_available_parking_spots, parking_record_id
vehicle_size could be COMPACT, STANDARD or OVERSIZED.
getParkingFee(parking_record_id: string)->fee:float
exit(parking_record_id: string)->leftFee:float
processPayment(parking_record_id: string, payment_id: string, payment_method: enum, card_info: object)
payment_method could be cash, debit or credit
High-level design
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design...
This system contains following components:
Client - user-facing UI machines at entrances and exits of the Parking lot.
Server - The main business logic lives here.
Database - Holds table to track current number of available parking spots. As well as recent parking record and payment record.
External Payment System - a third party payment system that takes payment (e.g. square)
Cron machine - Running a cron job to obtain old records (probably records older than 1 year and stores them in cold storage), the records could be cleared up in Database.
Cold Storage - Low cost storage to store old record, as they're seldom accessed.
Detailed component design
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
Cron machine & cold storage: The past parking records and payment records might be useful for future reference, audition, etc. However, it is not accessed very frequently, therefore, a cron job could be setup to run monthly and pull data that's over 1 year ago and store them in s3.
Server: we have very low traffic so 1 machine could handle all traffics. However, in order to ensure the availability of the service, we introdcue duplication in the server. We can have multiple (3 might be good enough) machines to serve the data. Whenever a client calls the service, it can use a round robin mechanism to choose a server to call.
Database: Similar to server, we are not expecting a huge number of data, and the data can fit in to one machine. However, in order to avoid downtime introduced by machine crashing or maintenence, we should introduce replica of the database. The database could run in master - slave mode, and the master is responsible to copy data over to slaves. In case the master machine is unavailable, a slave machine will then become the new master.
Database design
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
PARKING SPOTS TABLE:
- id: varchar (PK)
- spot_type: varchar (compact, standard, oversized)
- total_spots: integer
- taken_spots: integer
- updated_at: timestamp
VEHICLE PARKING RECORD TABLE:
- id: varchar (PK)
- license: varchar
- enter_at: timeStamp
- exit_at: timeStamp
PAYMENT RECORD TABLE:
- id: varchar (PK)
- vehicle_parking_record_id: varchar (FK)
- fee: float
- payment_method: varchar (cash, debit or credit)
- card_info: object (metadata of the card used in payment)
- external_payment_id: varchar
- paid_at: timeStamp