Building Carousel Part I: How We Made Our Networked Mobile App Feel Fast and Local
Article Summary
Dropbox's Carousel team faced a brutal truth: their photo app was slower than local galleries, and users noticed. No one wants to wait for network requests just to delete a photo.
This deep dive from Dropbox Engineering explains how they rebuilt their mobile photo app architecture from the ground up. The goal was ambitious: make a cloud-backed gallery feel as fast as native device storage.
Key Takeaways
- Humans perceive delays at 100ms, so blocking network calls were eliminated entirely
- Built eventually consistent system using optimistic replication and operation queues
- LUIDs (locally unique IDs) let users modify photos before upload completes
- HTTP long polling plus delta API keeps client synced with server changes
- SQLite stores three data sources: server photos, pending uploads, and user operations
By treating local and remote photos as equivalent objects and replaying pending operations on cached server state, Carousel eliminated all user-facing network waits.
About This Article
The carousel needed to handle collections with over 100,000 photos without slowing down. The team had to focus on memory management and work around Android's garbage collector limitations.
Dropbox built a delta-based architecture that keeps the photo model in memory and updates it as new changes come in. They added a delta layer between disk and memory to reduce latency.
By treating local and remote photos as the same type of object, users could share and delete photos instantly. Network delays became invisible, so the app no longer needed blocking HTTPS requests that made users wait.