parkingSystem
Desgin an Efficient Parking Lot System
System Requirements
- User can reserve a parking spot.
- User pays for the reservation.
- User can park a car on the parking spot.
- User can leave before the reservation time expires.
- There are three different parking spots - compact size, standard size, and with electric charger.
- One common error case to handle is when a user makes a reservation, but fails to show up. In this case, we would charge for the first 24 hours.
User: reserve, pay, park
Parking spots: types
Case: make reserve but not come, still need to pay the first
Capacity Estimination
operations in 10 countries
each country 100 parking plots
average 50 reservation request per day
total —> 1000 parking plots —> 50 000 request per day
each request:
user id (20 bytes)
car type (1 byte)
start time (8 bytes)
end time (8 bytes)
----> 40 bytes total —> per day 400 KB data —> 2 year 292 MB
choose RDB
because --> strong consistency, avoid dobule booking
response time is not very hard
even if it may take a couple of seconds, would be acceptable
API Design
-
检查是否full
地点 lot_id
需求 vehicle_type
时间 start-end time
check_capacity(lot_id, vehicle_type, start_time, end_time)
-
reserve
谁 user_Id
在哪 lot_id
做了什么 vehicle_type
什么时候 start-end time
Reserve_spot(user_id, lot_id, vehicle_type, start_time, end_time)
-
pay
谁 user_id
账单 reserve_id
Pay(user_id, reservation_id)
Database Design
Reservation table(Reservation)
Lot table(Record parking)
Vehicle_type table (supprt car types)
Transcation table (record vehicle enter/exit logs)
High-Level Design
client and API gateway
reservation System + payment System
transaction service
Request Flows
client 客户端
用户 通过 clietn 发送 request
eg:
Reserve a parking space
Check the capacity of parking lot
CDN
CDN is used as cache and sending static content.
Eg: JS, CSS or static resources of applications
Rate Limiter
prevent Malicious attacks and overuse of system resources
Load Balancer
allocate the requests into mutiple API gateway or services
API Gateway
the interface beteween service and client
responsible for routing request to suitable service
also responsible for cross-service aggeration.
负载均衡器主要关注的是Improve service availability and performance，
API网关则更加注重Manage and optimize API usage.
Reservation Server
handling logic related to reserve
create, query, manage reservation
Transaction Server
handling transaction related to vehicles entering and exiting the parking lot.
Database
store data related to reservation and transaction.
persistence of the system
Cache
store the common used data
results of popular queries
frequently accessed data
Message Queue
asychronous processing tasks —> handing payment requests
Payment System
handing all the operations realted with payments
payment of user reservation
在您提供的停车场系统架构图中，每个请求从客户端开始，然后通过一系列的系统组件，最终实现用户的预定或交易处理。这里是具体的步骤和流程：
- 客户端发起请求： 用户通过客户端（例如，移动应用或网页）发起一个请求，如查询停车场的可用性、预订停车位或者支付停车费。
- 通过CDN： 请求首先可能经过一个内容分发网络（CDN），这主要用于处理静态资源请求。如果请求是动态的，如API调用，它会继续传递给下一层。
- 速率限制： 在速率限制器（Rate Limiter）这一层，系统会检查请求的频率，防止过高的请求速率导致服务拒绝（DoS）攻击或资源过载。
- 负载均衡： 负载均衡器（Load Balancer）接收来自速率限制器的请求，并将其分配给后端的多个服务器之一，如API网关，以确保处理负载均匀分布，提高系统的响应能力和可用性。
- API网关： API网关作为一个中心节点，接收来自负载均衡器的请求，并根据请求的性质将其路由到相应的服务器，如预订服务器或交易服务器。
- 预订服务器和交易服务器处理：
- 预订服务器：处理与停车预订相关的逻辑，如接受新的预订请求、处理查询可用车位的请求或管理预订状态的变更。
- 交易服务器：处理与车辆进出记录相关的事务，如记录车辆的进入和离开时间。
- 数据库和缓存的交互：
- 数据库：用于持久存储预订数据和交易数据，预订服务器和交易服务器都会与数据库进行交互来读取或更新数据。
- 缓存：减轻数据库压力，提供快速的数据访问。常用数据，如热门车位的预订状态或频繁查询的用户信息，可以缓存以加快响应速度。
- 消息队列：
- 在某些操作，特别是需要异步处理的操作（如支付请求）中，预订服务器会向消息队列发送消息，消息队列负责安排这些消息按顺序发送到支付系统。
- 支付系统：
- 支付系统处理与支付相关的所有任务，例如从消息队列接收支付指令，处理支付事务，并返回支付状态给预订服务器或直接反馈给客户端。
整个流程设计确保了系统能在高负载情况下稳定运行，同时通过异步处理和缓存策略来优化性能和响应速度。这样的设计使得系统能够高效地处理大量并发请求，保持高可用性和扩展性。
Reference
Others information