Build a multi-tenant Image Processing Pipeline

Question

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

Codemia · Accepted Answer

- **Functional Requirements:**
  - Support multi-tenant architecture for different clients allowing them to process images independently.
  - Image processing tasks include resizing, filtering, and format conversion.
  - Provide APIs for image upload, status check, and retrieval of processed images.
  - Support webhook notifications for completion of processing tasks.
  
- **Non-Functional Requirements:**
  - Scalability to handle millions of requests per day with varying loads.
  - High availability with minimal downtime (99.9% uptime).
  - Low latency in processing (average under 200ms for image processing tasks).
  - Security measures to protect images during transit and at rest, including encryption and access control.
  - Compliance with data protection regulations (e.g., GDPR, CCPA).

- **Daily Requests:** Assume 1 million users, each processing 10 images per day on average. Total requests = 10 million requests/day.
  
- **Requests per Second (QPS):**
  - Total requests per second = 10 million / 86400 seconds = ~115.74 QPS.
  
- **Storage Estimation:**
  - Assume average image size of 500 KB. Total daily storage = 10 million * 0.5 MB = ~5000 GB (or ~5 TB/day).
  - With retention for 30 days: ~150 TB storage required.
  
- **Bandwidth Estimation:**
  - Total bandwidth = 10 million requests * 500 KB = ~5000 GB/day or ~207 Mbps.

- **Component Diagram:**
  - **API Gateway:** NGINX/HAProxy for routing API requests.
  - **Image Processing Service:** Microservices built using Python (Flask) with Celery for task queues.
  - **Message Queue:** RabbitMQ or Kafka for asynchronous processing of image tasks.
  - **Storage:** S3 for raw images and processed results. RDS (PostgreSQL) for metadata.
  - **Cache Layer:** Redis for caching frequently accessed image metadata and results.
  - **CDN:** CloudFront or Fastly for serving processed images to reduce latency.
  - **Monitoring:** Prometheus for metrics and Grafana for dashboards, along with Sentry for error tracking.

- **Schema Design:**
  - **Users Table:** (user_id, username, email, tenant_id, created_at)
  - **Images Table:** (image_id, user_id, status, original_url, processed_url, tenant_id, created_at, updated_at)
  - **Processing Jobs Table:** (job_id, image_id, processing_type, status, created_at, completed_at)
  
- **Access Patterns:**
  - Query images by user ID and tenant ID for isolation.
  - Fetch processing status using job ID for real-time updates.
  - Ensure quick access to processed images via CDN links.

- **Consistency vs Availability:**
  - Opting for eventual consistency in processing results to ensure higher availability and faster response times. Using a message queue allows processing to occur asynchronously without blocking user requests.
  
- **Caching Strategy:**
  - Using Redis for caching metadata to reduce database load but may introduce stale data issues. Use cache invalidation strategies based on job completion events.
  
- **Partitioning Strategy:**
  - Sharding images and jobs by tenant_id to ensure isolation and reduce cross-tenant contention.
  
- **Failure Handling:**
  - Implement retry mechanisms in the image processing service for failed jobs, and use dead-letter queues to handle unprocessable messages.

Build a multi-tenant Image Processing Pipeline

Robinhood

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

Capacity Estimation

Submit Your Answer

Robinhood 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