Building a Media Rights Dashboard: Notes on Multi-cloud SaaS for Digital Rights Holders

Patrick Donahue · Levelbrook Consulting

The business of digital media is fundamentally a business of managing rights. An artist's song, a studio's film, or a creator's video isn't a single entity but a constellation of licenses, royalty streams, and usage policies scattered across a dozen different platforms. Each platform—YouTube, Spotify, Apple Music, TikTok—is its own cloud, its own silo, with a unique API, data format, and set of rules. For a rights holder, this isn't just an inconvenience; it's an existential data aggregation problem.

Building a SaaS platform to unify this view is a fascinating engineering challenge. It's not about building a simple CRUD app. It’s about creating a coherent source of truth from a high-velocity stream of heterogeneous, and often conflicting, data. The "multi-cloud" aspect here isn't about where our own service is deployed, but about the nature of the world it must consume. This is a system that imposes order on digital chaos.

Architecting for Controlled Chaos

Let's consider a hypothetical stack for this dashboard: a Python backend for data ingestion, MongoDB for its flexible schema, and a modern JavaScript frontend like Vue.js with TypeScript. This choice is deliberate, favoring tools that excel at handling disparate data and building responsive user interfaces.

The Ingestion Engine and Data Model

The core of the system is a robust data ingestion pipeline. A Python backend with a distributed task queue like Celery or Dramatiq is a natural fit. Each platform integration becomes a set of workers responsible for fetching data—assets, performance metrics, royalty statements, and content claims. These jobs must be resilient, handling rate limiting with exponential backoff, managing rotating API keys, and normalizing data on the fly.

A document database like MongoDB shines here. The data from various platforms will never fit a rigid relational schema. One platform provides ISRC codes, another uses its own internal ID; royalty statements can be monthly PDFs or daily CSVs. A flexible document model allows us to store this raw, source-of-truth data without losing fidelity.

A simplified document for a single creative work, an `Asset`, might look like this:

{
  "_id": ObjectId("..."),
  "title": "A Day In The Life",
  "artist": "The Beatles",
  "isrc": "GBAYE6700012",
  "internal_id": "asset_123",
  "platform_data": [
    {
      "platform": "spotify",
      "platform_id": "42nWNp5mIGJOhK8aC4B9S9",
      "url": "https://open.spotify.com/track/...",
      "metrics": { "streams": 120540123, "updated_at": "..." }
    },
    {
      "platform": "youtube",
      "platform_id": "usNsCeOV4GM",
      "content_id_claims": [
        { "claim_id": "yt_claim_abc", "status": "active", ... }
      ]
    }
  ],
  "royalty_statements": [
    { "source": "distributor_x", "period": "2023-Q4", "amount_usd": 15023.45, ... }
  ]
}

This structure allows us to link disparate platform-specific entities back to a single canonical `Asset`. The real work is in the logic that populates and reconciles this document over time.

A Real-time, Reactive Frontend

The user of this dashboard is a rights manager, whose job is to spot problems. They need to see a new copyright claim, a sudden drop in royalties, or an unauthorized usage alert, *now*. This demands a reactive frontend architecture.

A stack like Vue.js with Pinia for state management and TypeScript for type safety is a strong contender. The interface would be component-based: a global dashboard for high-level KPIs, a searchable asset library, and a detailed asset view that aggregates all platform data. My experience building real-time UIs with tools like Turbo Streams and WebSockets in other ecosystems like Rails reinforces the importance of the transport mechanism. For this system, Server-Sent Events (SSE) would be an excellent choice. It's a simpler protocol than WebSockets and perfect for the server-to-client data flow that dominates this use case: "A new claim has been detected on Asset X," "Royalty statement for Q1 has been processed." The server pushes updates, and the Vue components, observing the Pinia store, reactively update themselves.

The UX must be designed around highlighting anomalies. Data tables are fine, but the real value is in visualizations that show royalty trends over time or flag a video on YouTube that has millions of views but no corresponding monetization claim.

Pragmatism: Human-in-the-Loop and LLMs

Automation is the goal, but complete automation in rights management is a fantasy. The edge cases are too numerous and the financial stakes too high. A senior engineering approach embraces this reality with a "human-in-the-loop" design.

This is where AI/LLMs move from buzzword to practical tool. Consider the problem of asset matching. A rule-based system might fail to link `My Song (Official Video)` with an unauthorized upload titled `my song (live performance)`. However, by generating text embeddings for titles and descriptions, we can use vector similarity search to flag these as *potentially* related. The system doesn't automatically file a takedown; it creates a task in a review queue: "We found a video with 89% title similarity to your asset 'My Song'. Please review."

Similarly, many smaller distributors still send royalty statements as PDFs. An LLM with vision capabilities can perform OCR and structured data extraction to parse these documents, but the output is never guaranteed to be 100% correct. The pragmatic approach is for the LLM to generate a proposed JSON representation of the statement and present it alongside the original PDF for a human to verify with a single click. The goal is to augment the human expert, not replace them, turning a 30-minute data entry task into a 30-second confirmation.

Where It Breaks at Scale

A system like this faces several scaling bottlenecks:

1. API Rate Limits: Managing a catalog of a million songs across 20 platforms means billions of API calls. This requires a sophisticated job scheduler that understands per-platform rate limits, priorities (financial data is more important than view counts), and graceful degradation.
2. Data Storage: The `platform_data` arrays can grow indefinitely. We need strategies for archiving historical time-series data and thoughtful MongoDB indexing on high-cardinality fields like `platform_id` and `isrc`.
3. Deployment Complexity: This isn't a monolith. It's a collection of services: the web app, the ingestion workers, a database, a vector store, a job queue. Managing this with Docker is a given. Tools like Kamal can simplify deployment by managing containers across multiple servers without the overhead of full-blown Kubernetes. Leveraging a service like Cloudflare for CDN, but also for its Edge Workers, can offload tasks like request signing or caching API responses close to users, reducing global latency.

A Reflection on the Problem

The challenge of building a media rights dashboard is a microcosm of modern software engineering. It's a data-intensive application that must interact with a messy, multi-vendor world. The solution requires a polyglot approach, combining the strengths of different tools—the data-wrangling of Python, the reactivity of modern JavaScript, the flexibility of a document database, and the pattern-matching power of LLMs. Success isn't measured by the elegance of any single component, but by the system's ability to create a clear, actionable signal from a world of noise.