SYSTEM Cited by 1 source
Dropbox Riviera¶
Overview¶
Riviera is Dropbox's universal content processing platform — a shared infrastructure service that transforms files between formats at massive scale. It started ~2014 as an internal preview-generation service and evolved over a decade into a multi-product platform now exposed as a public API and via MCP tools.
Architecture¶
Riviera's architecture separates coordination from execution:
- Central coordinator — validates requests, composes the work to be done (selects which transformation steps are needed), caches results, dispatches work to backend workers, and deduplicates requests. Protects backends from invalid or redundant traffic.
- Backend workers — each worker type owns a single transformation capability (e.g., "PDF to page images", "video to streaming manifest", "document to extracted text"). One point of maintenance and scaling per capability.
- Plugin model — new transformations are added as plugins. Product teams can contribute plugins while the Riviera team maintains core infrastructure.
This coordination/execution separation lets each capability scale independently. The coordinator layer handles cross-cutting concerns (caching, deduplication, request validation) while workers remain focused on their single transformation type.
Composable transformation pipelines¶
The key insight is that complex processing tasks decompose into sequences of reusable primitives:
- PowerPoint preview → PowerPoint-to-PDF → PDF-to-page-images
- PDF preview → PDF-to-page-images (reuses the same step)
- Document indexing → format-to-text-extraction
- Video review → video-to-transcode → transcode-to-streaming-manifest
The same transformation step (e.g., PDF-to-image) is shared across multiple products and use cases. This is the composable transformation pipeline pattern.
Scale¶
| Metric | Value |
|---|---|
| Transformation capabilities | >100 |
| Supported file formats | >300 |
| Throughput | Hundreds of thousands of transformations/second |
| Daily video output equivalent | ~8 years of video |
| Internal consumers | Previews, Search, Replay, Sign, Dash, ML |
| Platform age | ~10 years (started ~2014) |
Internal consumers¶
- Previews — the original use case. Renders file previews across all Dropbox surfaces (web, mobile, desktop) for >300 formats.
- Search — prepares documents for indexing (text extraction, OCR).
- Replay — video transcoding and manipulation for the video review product.
- Sign — document flattening into PDF for agreement finalization.
- Dash — content preparation for AI (text extraction, format conversion, metadata extraction) before documents enter the Dash search index and answering pipeline.
- ML teams — image normalization for feature extraction (e.g., consistent 160×160 thumbnails).
Platform evolution trajectory¶
- Internal tool (~2014) — preview service owned by a dedicated team.
- Organic adoption — Search, then other teams, discovered they could reuse transformations instead of building new infrastructure.
- Shared platform — plugin model opened to product teams; Riviera team owns core, product teams contribute capabilities.
- AI enabler — Dash built on existing capabilities for AI content processing.
- External API (2026) — capabilities exposed via public API and MCP tools for external developers.
This trajectory embodies concepts/platform-evolution — the progression from single-purpose internal tool to shared infrastructure to externalized capability.
Design principles¶
- Reusable transformations over one-off pipelines — avoid duplicating logic across services by decomposing into composable primitives.
- One point of maintenance per capability — each transformation type has a single owner and scaling profile.
- Coordinator protects workers — caching + deduplication at the coordination layer reduces load on backends.
- Plugin-based extensibility — core stays stable while capabilities expand (patterns/plugin-based-extensibility).