Loading...
List the key functional requirements for the system (Ask the AI for hints if stuck)...
count and location of free spases, pay system for the spaces, like pay cards, special spases for bikes and for electrocars, how much should the person pay for time
book the parking space for what type of transport and for what time
control when the wehicle arrive ang leave
what if 2 people wanna book the same space in one time period
in falure what should we save awailability or consisrensy?
what if person book a place but don't stay on it
user shoud go to the parking, check free spase, book it spase, pay for it, leave his car.
List the key non-functional requirements (performance, scalability, reliability, etc.
the system should be fast(answer <200 ms), simple user interface, relible(awailability on 99.9%)
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
for instance we have 1000 users in a day we multipply on users request(about 3-4)/100000
for high capasity we need to multiply this rps on 3-4
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
if the car is registrated?(api get (id))
registration(api post(some fields))
pay(api post(id, sum))
all services communicate during apis, when user send a request, that he wanna parcking in this time, choose the place on the screan, the system check is this client already registrated, if not we go to the registration service for registration, after that we check is this place free, if it is free we try to get pay for it in this time we block this place, if there are some problems with banks or card, we rollback booking
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
front then api gateway then microservices(payment,calculation, tracking, registration)
sql db, redis for cashe
we get a request, firstly it goes to the gateway and check registration, then go to the service we need, if this request for getting data we check reddis cashe firtly, if it is clear go to the db. we may olso add read repica and use cqrs pattern. Also we may use hybrid cashe.
if we say about writing data we use sql db cause we have structure of our tables, we need not the functianality of any other db cause the sql cover all of our needs
we will use horisontal scaling, add Load Balancer and race limited for periods of high capacity in this case users may wait some seconds more but the system will work without crush errors
accoring to cap- theorem in failure we may loose awailability, cause if the user pay for place but is already busy it cause more prolems than anawailability of the system
when user try to book the space we just lock this row in db and the place seems busy , so that no one can book it again
accotding nfr the system should be fast so we add cashe to decrease nework requests.
the system is deployed in kubernetis and added load balancer for keeping scalability, also the sustem uses read-replicas for reading data
the db is in master-salve mod so that in failure the db switch on the followers server. also the paiment server use retries and rollbacks
we add time-out for no-show cases, and the place will available if the tracking server says that car is not here
we add time to live for cashe, so that the data will be trandy
we should add Gate Check-in / Check-out and track the time when the car go in or go out.
if we loose internet connection in aou parking, we will use the local gate cashe, wich is updatet some times during the day
for hot lots we may add Rate Limiting, wich will allow parking only current amount users, and other should wait some seconds
Surges in demand are handled through Rate Limiting and message queues (Kafka). The stale cache issue is resolved by deleting the key from Redis immediately after a successful SQL write (Cache Invalidation).
Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...
sql db, table cars, users(one 2 many),index to user name, cur number is unique
sharding for regions
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
all of them work in k8s, this system not for big amount of users, less than 4000, for booking we use transaction isolation lavel reapitable read, use SELECT ... FOR UPDATE to prevent race codition,also we need to have reddis checking and db transaction is one rtansaction to prevent incotect data in cache before, for payment we need to use transaction system if the pay not get the place become free and user may try again