Practice/Atlassian/Design a Color Picker

Design a Color Picker

System DesignOptional

Problem Statement

Design a color picker application that allows users to select colors, save them as favorites, and share their favorite colors with friends. The system should address scalability challenges, performance bottlenecks, and explain why some users might experience degraded performance under high load while others do not.

This is a distinctly Atlassian-flavored question that looks deceptively simple but forces you to think through a full product lifecycle. Interviewers typically frame it as a one-day hackathon project: first build a working MVP, then add sharing, then reason about what breaks at scale. They want to see pragmatic technology choices for the MVP, a clear path from monolith to scaled architecture, and your ability to diagnose uneven user impact under load. The question tests fundamental system design instincts rather than complex distributed systems theory.

Key Requirements

Functional

• Color selection -- users pick a color using a visual interface and see an immediate preview with HEX, RGB, and HSL values
• Favorites management -- users save, view, and remove colors from a personal favorites list that persists across devices
• Sharing -- users share a single color or an entire favorites collection with friends via a link or in-app message
• Cross-device access -- favorites sync reliably across web and mobile clients through user accounts

Non-Functional

• Simplicity -- the MVP must be deployable in a one-day hackathon; start with the simplest viable architecture
• Scalability -- after launch, support millions of users with read-heavy favorites retrieval and occasional sharing spikes
• Latency -- color preview must be instant (client-side); favorites load within 200ms; shared link resolution within 300ms
• Reliability -- favorites must never be lost; sharing must be durable even if the recipient is offline

What Interviewers Focus On

Based on real interview experiences at Atlassian, these are the areas interviewers probe most deeply:

1. MVP Architecture Choices

Interviewers want to see that you can ship a working product quickly. Overengineering with microservices and distributed databases on day one is a red flag.

Hints to consider:

• Start with a monolithic application (Next.js or Django) backed by a single PostgreSQL database
• Color selection and preview are entirely client-side: an HTML canvas or slider component, no server round-trips
• Store favorites as rows in a simple relational schema: users table, favorites table with (user_id, color_hex, created_at)
• Deploy to a single server or managed platform (Vercel, Heroku) to minimize infrastructure complexity

2. Adding Sharing and Scaling Writes

Once sharing is introduced, the system handles more complex flows. Interviewers probe how you add this feature without breaking the MVP's simplicity.

Hints to consider:

• Generate a unique share token (UUID or short hash) stored in a shares table linking to the user's favorites snapshot
• For sharing via link, create a public endpoint that resolves the token and returns the color or collection
• Send in-app messages or notifications asynchronously through a message queue (SQS or Kafka) to avoid blocking the share action
• Make share creation idempotent using the token as a natural deduplication key

3. Diagnosing Bottlenecks at Scale

Interviewers push you to reason about what breaks when millions of users join. They specifically ask why some users experience issues while others do not.

Hints to consider:

• Popular users who share widely create hot rows: their favorites and share records are read far more often than average, causing lock contention on the database
• Uneven geographic distribution means users far from the server experience higher latency; a CDN and regional read replicas help
• Cache stampedes occur when many users request the same shared collection simultaneously after cache expiration
• Tail latency affects users whose requests happen to hit a slow database replica or a garbage collection pause

4. Scaling the Architecture

From the simple MVP, interviewers want to see a credible evolution path to handle load.

Hints to consider:

• Add Redis as a caching layer for favorites lists and share token resolution, with TTLs aligned to update frequency
• Move to read replicas for PostgreSQL to handle the read-heavy favorites workload
• Rate-limit the share endpoint to prevent abuse and notification storms from bots or retries
• Introduce a CDN to serve the static color picker interface and shared collection pages, reducing origin load
• Partition the database by user ID if a single PostgreSQL instance can no longer handle the write volume