Design A Color Picker Service
A color picker service provides a backend that enables users to explore, select, and store their preferred colors. After authenticating, users can choose colors they like and have those choices permanently recorded. Additionally, users can share specific colors through a URL, making them accessible to anyone, whether they are logged in or not.
2. Requirements
My first point of clarification with the interviewer would be: are we designing the interactive color selection widget, or the backend system responsible for storing and delivering colors? The focus is the backend. A critical follow-up question: could a shared color experience viral popularity? If the answer is yes, the system evolves beyond straightforward CRUD operations. It transforms into a content delivery challenge masked as a configuration interface.
Functional requirements
- Users must be able to register and authenticate (log in/log out).
- Authenticated users can select and save one or more favorite colors; each entry is stored as a hexadecimal color code along with an optional descriptive label.
- Users can fetch their previously saved favorite colors.
- Users can create a shareable link for any saved color. This link allows anyone, including unauthenticated visitors, to view that specific color.
- The system must support celebrity-user amplification, where a single individual’s shared color might be accessed by over
100,000simultaneous users.
Out of scope (below the line)
- Rendering of colors, the frontend color-picker interface, or any user-interface logic
- Algorithms for generating color palettes (e.g., complementary colors, gradients)
- Social networking features beyond sharing (no commenting, liking, follower graphs, or activity feeds)
- Real-time collaborative color editing
- Administrative dashboards, content moderation tools, billing integration, or subscription levels
Non-functional requirements
- Availability: Target
99.9%uptime for both the personal color management API and the shared-color retrieval path. - Read latency: Shared-color pages must load within
200 msat the 99th percentile globally, even during celebrity-driven traffic surges. - Write latency: Saving a personal color must complete within
300 msat the 99th percentile. - Scale: The minimum viable product (MVP) begins with roughly
100users and must scale to10 millionregistered accounts. Celebrity-shared colors may draw100,000+concurrent viewers. - Durability: Once the API confirms a successful save, user color preferences must never be lost.
- Observability: The system requires structured logging, latency percentile tracking, cache hit ratio monitoring, and alerting on error rates.
Back-of-the-envelope estimation
| Metric | Value | Design consequence |
|---|---|---|
| Registered users (scale target) | 10M | A single PostgreSQL primary with read replicas is sufficient |
| Max colors per user | 100 | Total color rows are bounded at roughly 1 billion in the worst case; realistically, the number is far lower |
| Color record size | ~200 bytes (hex, label, metadata) | The entire color dataset fits easily within a single database |
| Shared-color reads (celebrity peak) | 100k+ concurrent | The database alone cannot serve this load. A CDN is mandatory |
| Shared-color payload | < 1 KB | Extremely small and highly cacheable at the network edge |
| Write queries per second (QPS), normal | Low hundreds | Easily managed by AWS Lambda or a small fleet of containers |
| Read QPS (celebrity spike) | 100k+ | Amazon CloudFront absorbs this traffic. The origin receives approximately one request per time-to-live (TTL) window per edge location |
The defining numbers for this architecture are the celebrity read spike and the minuscule payload size. The CDN’s TTL governs the frequency of origin contact. Together, these factors reveal that the system is not fundamentally a database scaling exercise; it is a CDN caching strategy problem. The database remains compact and uncomplicated, while CloudFront carries the vast majority of the load.
High‑level architecture – CDN absorbs celebrity read spikes while writes and personal reads hit the application and database.
