document-processing

2 posts

dropbox

How our universal content processing platform Riviera evolved for AI and beyond (opens in new tab)

Riviera evolved from Dropbox’s preview-generation service into a shared content-processing platform used by products including Search, Replay, Sign, and Dash. Its core insight was to compose reusable transformations rather than build separate pipelines for every file type and output. As AI increased demand for consistent document extraction and preparation, Dropbox expanded Riviera’s capabilities and began offering them through APIs and Model Context Protocol tools. ## The Preview Problem - Dropbox supports more than 300 file formats, each requiring outputs such as: - Thumbnails - Full previews - Extracted text - Streaming manifests - Metadata - Building a separate service for every format and output would duplicate logic, dependencies, and operational work. - Configurations and package versions could drift across services, making the system harder to maintain and scale. ## Reusable Transformations as the Foundation - Riviera treats previews as sequences of smaller, reusable transformations. - For example, a PowerPoint preview can be produced by: - Converting the presentation to PDF - Rendering each PDF page as an image - The same PDF-to-image transformation can support PDFs and other workflows requiring page images. - This approach enables new formats and products to reuse existing capabilities instead of starting from scratch. ## Separating Coordination from Execution - Riviera uses a central coordinator to: - Collect and validate requests - Compose transformation workflows - Cache responses - Dispatch jobs to backend workers - Each worker handles a specific transformation, creating a clear unit for maintenance and scaling. - The platform now includes more than 100 capabilities and performs hundreds of thousands of transformations per second. - New formats and transformations can generally be added as plugins without changing the core system. ## From Internal Service to Shared Platform - Other Dropbox teams quickly adopted Riviera when they discovered overlapping content-processing needs. - Machine learning teams reused preview thumbnails for image normalization, avoiding duplicate generation. - Search used Riviera to prepare documents for indexing, while Sign, DocSend, and Replay reused existing transformations. - Dropbox eventually opened the plugin model to product teams, allowing them to add capabilities while the Riviera team maintained the platform’s core architecture. - Replay particularly benefited from Riviera’s complex video transcoding and manipulation capabilities, accelerating product development from months to weeks. ## Supporting AI Workloads - Dash introduced greater demand for reliable document preparation before AI processing. - AI systems require content to be transformed into consistent, machine-readable representations, including: - Extracted text - Data from scanned pages - File metadata - Normalized versions of hundreds of file types - These are fundamentally content-transformation challenges rather than AI-model challenges. - Because Riviera already supported many formats and transformations, Dash could build on existing infrastructure instead of creating a separate document-processing system. ## Broader Availability - Dropbox is making Riviera’s capabilities available to external developers and design partners. - Access is provided through APIs and Model Context Protocol tools. - The platform is intended for applications such as content management, document automation, search indexing, and AI document processing. Riviera’s evolution demonstrates the value of a shared transformation platform: reusable workers reduce duplication, centralized coordination improves reliability, and each new capability benefits multiple products. For teams building content-heavy or AI-powered applications, using standardized transformation infrastructure can be more efficient than maintaining format-specific pipelines independently.

figma

A deep dive on deep search | Figma Blog (opens in new tab)

Figma’s deep search lets users find files by searching text inside them rather than relying on file names or metadata. Building it required extending infrastructure originally created for Design System Analytics to process `.fig` files stored in Amazon S3. Because analyzing large file trees is expensive, Figma accepted briefly stale results and processed deduplicated changes hourly. ## Deep Search in a Browser-Based Product - Figma’s web-based architecture provides detailed access to files and usage data. - This enables features such as: - Component usage analytics - File-view frequency - Inspection of file structure - Searching content inside files - Deep search builds on the browser’s collaboration and discoverability advantages. ## Reusing Design System Analytics Infrastructure - Design System Analytics already opened recently edited files, retrieved them from storage, and traversed their contents. - Analytics extracted shared-library usage information. - Deep search applies the same general workflow to extract text from Figma files. - The existing file-analyzer worker platform provided support for computationally intensive, periodic processing. ## Regular Search vs. Deep Search - Regular search indexes database metadata, including: - File name - Creator - Folder ID - Team ID - Its pipeline: - Database changes are streamed into a messaging system. - Search indexers retrieve current records. - The metadata is indexed in Elasticsearch. - Deep search cannot rely on database metadata because the actual file contents are stored as `.fig` documents in Amazon S3. - A `.fig` file is represented as a tree of nodes, such as frames, rectangles, vectors, ellipses, and text objects, each with its own properties. ## Managing the Cost of File Analysis - Retrieving and traversing a complete Figma file is significantly more expensive than reading database records. - Files may contain thousands of nodes, and users can trigger saves approximately every 30 seconds. - Re-indexing every save would produce substantial duplicated computation. - Figma therefore: - Deduplicates file changes over one-hour windows. - Sends changed files to file-analyzer workers. - Allows deep-search results to be temporarily stale. - This tradeoff reduces server workload while maintaining useful search functionality. Deep search demonstrates how content-aware features require different infrastructure from conventional metadata search. Periodic, deduplicated processing offers a practical balance between timely results and the high computational cost of analyzing complete design files.