Design a Image Processing Service

Question

Design a fault-tolerant image processing system that handles millions of requests. Discuss trade-offs in consistency, availability, and performance.

Codemia · Accepted Answer

### Functional Requirements
1. **Image Upload**: Users can upload images via a REST API.
2. **Image Processing**: Support functionalities such as resizing, compression, and format conversion.
3. **Image Retrieval**: Users can retrieve processed images with unique identifiers.
4. **Batch Processing**: Ability to handle multiple images in a single request.
5. **Image Metadata**: Store and retrieve metadata (e.g., upload time, dimensions, format).

### Non-Functional Requirements
1. **Scalability**: The system must handle millions of requests per day.
2. **Fault Tolerance**: The service should maintain availability despite failures.
3. **Latency**: Image processing should be completed within 200 milliseconds for standard operations.
4. **Consistency**: Ensure eventual consistency across multiple regions.
5. **Security**: All image uploads must be scanned for malware.

Assuming **1 million users** each uploading **5 images per day**, we can estimate the following:
- **Total Image Uploads**: 5 million images/day = ~58 images/sec.
- Each image averages **2 MB**, leading to a total storage requirement of **10 TB/day**.
- Considering a **replication factor of 3** for fault tolerance, we need to account for **30 TB/day** in total storage.
- With a peak traffic assumption of 10x during certain hours, we should design for approximately **580 images/sec** at peak.

### Component Diagram
- **API Gateway**: Using **AWS API Gateway** to manage requests and rate limiting.
- **Load Balancer**: **AWS Elastic Load Balancer** to distribute incoming requests to processing nodes.
- **Image Processing Service**: A cluster of **Docker containers** orchestrated by **Kubernetes** to handle image processing tasks.
- **Message Queue**: **Amazon SQS** for decoupling image upload from processing, ensuring reliability in message delivery.
- **Storage**: **Amazon S3** for storing images and **DynamoDB** for metadata storage.
- **Monitoring**: **Prometheus** and **Grafana** for metrics and alerts.

### Schema Design
- **Images Table (DynamoDB)**:
  - `ImageID` (PK): Unique identifier for each image.
  - `UserID`: Identifier for the user who uploaded the image.
  - `UploadTime`: Timestamp of when the image was uploaded.
  - `Status`: Enum for processing status (e.g., 'pending', 'processed', 'failed').
  - `Metadata`: JSON field containing image dimensions, format, etc.

### Access Patterns
- **Retrieve Image**: Query by `ImageID` for fetching processed images.
- **List User Images**: Query by `UserID` to fetch all images uploaded by a specific user.

### Architectural Decisions
1. **Consistency vs. Availability**: Opting for eventual consistency in favor of higher availability to serve users globally. This means users may not see their images immediately after processing due to asynchronous operations.
2. **Message Queue**: Using SQS introduces some latency for processing but ensures durability and fault tolerance by decoupling the upload from processing.
3. **Multi-Region Deployment**: Deploying in multiple AWS regions improves latency for users globally but complicates data consistency and requires conflict resolution strategies.
4. **Rate Limiting**: Implementing API rate limiting at the API Gateway level to prevent abuse but may affect user experience during peak times.

Design a Image Processing Service

Compass

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

Compass 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