Design Recommendation Infrastructure for IoT devices

Question

Design a event-driven recommendation system that handles millions of requests. Discuss trade-offs in consistency, availability, and performance.

Codemia · Accepted Answer

### Functional Requirements
1. **Event Ingestion**: The system must ingest IoT events in real-time from millions of devices.
2. **Recommendation Generation**: Generate personalized recommendations based on historical data and real-time events.
3. **User Feedback**: Collect user feedback on recommendations to improve future suggestions.
4. **API Interface**: Provide a RESTful API for devices to fetch recommendations and submit feedback.

### Non-Functional Requirements
1. **Scalability**: The system should scale horizontally to handle millions of requests without degradation in performance.
2. **Availability**: Aim for 99.99% uptime to ensure consistent service for users and devices.
3. **Latency**: Recommendations should be generated within 200ms of event ingestion.
4. **Security**: Implement OAuth 2.0 for secure API access and data encryption in transit and at rest.

Assuming we have 10 million IoT devices, each sending an event every minute:
- **Total Events Per Minute**: 10 million events.
- **Total Events Per Day**: 10 million * 60 * 24 = 14.4 billion events.
- If each recommendation request is triggered by an event, we can anticipate a similar scale for recommendation requests.
- Assuming 10% of events require a recommendation, that results in 1.44 billion recommendation requests per day, or 1,000 requests per second.
- To handle peak loads, we should plan for at least double that capacity, targeting around 2,000 RPS.

### Component Diagram
- **IoT Device**: Sends events to an API Gateway.
- **API Gateway**: Handles incoming requests, implements rate limiting, and forwards to the appropriate service.
- **Event Processing Service**: Utilizes a message queue (like Kafka) to asynchronously process events.
- **Recommendation Engine**: A microservice that consumes events, generates recommendations, and stores results in a database.
- **Database**: Use PostgreSQL for structured data storage and Redis for caching recommendations.
- **Feedback Service**: Collects user feedback and adjusts recommendation algorithms accordingly.

### Technology Choices
- **API Gateway**: Kong or NGINX for load balancing and routing.
- **Message Queue**: Apache Kafka for high-throughput event processing.
- **Database**: PostgreSQL for relational data and Redis for fast access to cached recommendations.

### Schema Design
1. **Devices Table**:  
   - `device_id` (PK)  
   - `device_type`  
   - `created_at`

2. **Events Table**:  
   - `event_id` (PK)  
   - `device_id` (FK)  
   - `event_type`  
   - `timestamp`  
   - `data` JSON

3. **Recommendations Table**:  
   - `recommendation_id` (PK)  
   - `device_id` (FK)  
   - `recommendation_data` JSON  
   - `created_at`

4. **User Feedback Table**:  
   - `feedback_id` (PK)  
   - `recommendation_id` (FK)  
   - `user_id`  
   - `feedback_type`  
   - `timestamp`

### Access Patterns
- Frequent reads from the Recommendations table. Caching using Redis to speed up access times.

### Trade-offs Considered
1. **Eventual Consistency vs. Strong Consistency**: Opted for eventual consistency in the recommendation engine to allow for faster processing and better scalability, accepting a delay in feedback processing to improve performance.
2. **Caching vs. Real-time Data**: Caching recommendations in Redis improves latency but risks serving stale data. To mitigate this, implement cache invalidation strategies based on event freshness.
3. **Single vs. Multi-region Deployment**: A single-region deployment reduces complexity but may introduce latency for global users. A multi-region deployment increases availability and reduces latency but adds complexity in data synchronization.
4. **Rate Limiting**: Implementing rate limiting at the API gateway helps prevent abuse but may affect real-time responsiveness for legitimate users under high load.

Design Recommendation Infrastructure for IoT devices

Supabase

What the Interviewer Expects

Key Topics to Cover

How to Approach This

Possible Follow-up Questions

Practice a Similar Problem on Codemia

Sample Answer

Requirements

Functional Requirements

Capacity Estimation

Submit Your Answer

Supabase Software Engineer Interview Guide

Related Questions

Design a high-throughput Inventory Management System

Design a low-latency Rate Limiting System

Design a fault-tolerant Payment System

Design a fault-tolerant Messaging System

Design Walmart Product Search