Technology · Database
MongoDB Development
Five platforms, one publishing system, campaign-shaped data: MongoDB is what we reach for when the data model needs to match how content agencies actually organize work, not force it into rigid tables.
Written by Ing. Hlib Yarovyi, Founder
publishing platforms tracked per campaign in a single MongoDB-backed automation system
MPSS organizes every asset, schedule, and content list by campaign — matching how the client agency already manages accounts — and tracks publish state independently across YouTube, Instagram, Threads, Reddit, and Telegram, each with different metadata shapes, caption limits, and OAuth token states. A rigid relational schema would have meant a migration every time a new platform with different fields was added; the document model didn't.
Where MongoDB Fits
We reach for MongoDB when the shape of the data varies by type in a way that would otherwise mean a wide table full of nullable columns, or a maze of join tables just to represent something that's naturally a single document.
MPSS is the clearest example: a YouTube Shorts post, an Instagram Reel, a Threads post, a Reddit submission, and a Telegram message all have genuinely different metadata — caption limits, required fields, API response shapes — but they all belong to the same campaign and the same content item. Modeling that as campaign documents containing per-platform publish records let the system add Threads, Reddit, and Telegram after the first version shipped, without restructuring what YouTube and Instagram already had working.
That same flexibility is what makes OAuth state manageable across five different platforms' token formats and refresh cycles inside one system, without a rigid schema forcing every platform's auth data into the same fixed set of columns.
What We Build With It
Campaign-Shaped Data Models
Documents organized the way the business actually thinks about the work — by campaign or client — rather than forced into a generic relational structure that fights the domain.
Multi-Platform Publish Tracking
Per-platform publish status, metadata, and failure state tracked independently within a shared content record, so a failure on one platform doesn't obscure success on another.
OAuth Token State Management
Flexible storage for connected-account credentials across services with different token formats, refresh cycles, and expiry behavior — without a schema migration every time a new platform is added.
Incremental Feature Expansion
New content types or platforms added without restructuring existing collections, which is what let MPSS grow from two platforms to five without a rebuild of its core data layer.
Common Questions
- Because each platform's publish data genuinely has a different shape — different metadata fields, different limits, different response formats. Modeling that relationally would mean either a very wide table full of nulls or a large set of join tables. MongoDB's document model lets each platform's data look like itself.
- It can, without discipline — which is why we still define and enforce a schema at the application layer, typically with TypeScript interfaces, even though MongoDB itself doesn't require one. The flexibility is for handling genuinely different document shapes, not an excuse to skip structure.
- Yes — that was the actual requirement behind MPSS. It launched with YouTube and Instagram, then added Threads, Reddit, and Telegram later without rebuilding the core platform, because new platforms just meant new document shapes in an existing collection, not new tables and migrations.
- It fits well anywhere the data naturally groups into self-contained records with some variation in shape — user-generated content, event logs, configuration data. It's a worse fit for data with heavy relational structure and strict consistency requirements across many linked records, where a relational database is usually the better call.
Need a Data Model That Matches How Your Team Actually Works?
We build MongoDB-backed systems for teams whose data doesn't fit neatly into rigid tables — campaigns, multi-platform content, and per-client variation. If you have a system in mind, we can scope it clearly.