系统要求和范围：

1. 从大量摄像头实时接收视频流
2. AI model辨别车辆（车牌，颜色，和车型）
3. 按车牌，属性搜索历史记录
4. 订阅alert（例如某车出现的时刻）

Non-functional requirements：

1. 近乎实时系统，端到端延迟控制在2到5秒
2. 高可用
3. 高可扩展

API设计

1. PUT /video {"id": "<cameraId> + <timestamp>"} -> 200OK: 摄像头存储视频
2. POST /vehicle {"color": <color>, "model": <model>, "license": <license>} -> [<vihicle>]: 查询车辆
3. PUT /alert {"license": [<license>]} -> 200OK: 创建车辆出现的alert

系统架构设计

架构图如下：

描述如下：

1. camera捕捉到video后向后端service发送put请求。后端service生成S3 presigned url传给camera。camera将video上传到S3。

2. analyzeService捕捉到S3有新的视频对象生成，将video发送给AI进行分析，并将结果存储到videoDB。

3. indexService捕捉到DDB有新的record生成，根据license和camera在DB里的信息，生成OpenIndex的document，存储到OpenSearch。

4. analyzeService查询topicDB，如果已经有关于该license的topic，即向SNS相关topic发送一个通知。

5. user可以通过queryService发送查询请求。为了处理hot query，我们可以加上redis作为cache。

6. 用户可以通过alarmService创建alarm topic。同时将device或者邮箱subscribe到相关的topic。

讨论

1. 使用到lambda，s3，sagemaker，ddb，opensearch，sns。需要注意的是ddb的scale基于partition。我们使用了ID,license，作为partition key。总体来说出现hot partition的可能性很低。OpenSearch需要详细设计index的shards和replica count。我们应该用多个小的index存储数据，比如每天一个index，来降低query的latency。

2. 我们有两个改变数据的api，put video和put alert。如果call失败，可以retry，因为我们可以保证我们的api call是idempotent的。更好的方式是我们可以考虑在service端加入queue。这样我们可以在service retry失败的操作。这样更加resilient，同时解耦了用户请求和请求的处理。

3. 时延问题。系统对时延要求比较高。按照我们目前的设计有两个问题，第一，对于完整video的上传可能会造成时延问题，第二，我们有两处通过CDC进行操作的异步处理，对时延也是一个risk。这里我们可以kaolv两个改进：第一，我们考虑在device或者edge增加处理能力，例如sample video，或者直接调用edge AI model进行预处理甚至完成AI调用。这样可以大大减轻service端的负载。第二，我们可以考虑使用Kafka和FLINK这样的流和流处理服务，在FLINK里完成对AI的调用和到OpenSearch document的整合。