How would you model cross-platform ad campaign data and adaptation logic?
Separating campaign intent from platform execution.
Propose a canonical model, platform adapters mapping copy to each schema, and an async pipeline with validation.
What's really being asked
This question tests your ability to design a layered architecture that insulates business concepts from external API volatility. The interviewer wants to see if you can model a single source of truth for campaign intent while respecting that each advertising platform has distinct object hierarchies, field limits, creative formats, and targeting rules. They are looking for evidence that you understand normalization, transformation pipelines, and operational concerns like partial failure and observability.
The full answer
A strong response starts with a canonical data model that captures the marketing team's high-level concept. This model should include campaign goals, audience segments, creative variants, and budget constraints without referencing any provider schema. Next, introduce a platform adaptation layer composed of provider-specific adapters or strategy objects. Each adapter knows how to map canonical fields into the target platform's native structures, such as Google Ads campaigns and ad groups or Meta ad sets and ads, while enforcing constraints like character limits and image aspect ratios. Then describe an asynchronous deployment pipeline that stages transformations, validates payloads against live or cached platform metadata, submits via each provider API, and captures execution state. Finally, explain how you handle drift when platforms change their APIs, such as versioning the adapter rules and using feature flags to roll out new mappings gradually.
The mistakes people make
A red flag is proposing a single database table with nullable columns for every possible platform field, which creates a sparse unmaintainable schema. Another mistake is suggesting synchronous sequential calls to each ad API during the user's save action, which ignores latency and failure isolation. Some candidates also forget constraint enforcement entirely, assuming that a headline written for Google will automatically fit TikTok's length limits or creative specifications.
What usually comes next
The interviewer may ask how you would handle a platform API deprecation without rewriting the entire system, or how you would support A/B testing a single creative variant across only two of five connected platforms. They might also probe how you would reconcile spend and performance data back into the canonical model when each platform reports metrics on different schedules and with different attribution windows.
A concrete example
Imagine a summer sale campaign with a hero headline, two body variants, and a set of images. The canonical record stores the headline as Summer Sale: 50 Percent Off and tags the images as square and vertical. The Meta adapter splits this into a campaign, an ad set with lookalike targeting, and two ads with vertical video. The Google adapter creates a search campaign with responsive search ads, truncating the headline if it exceeds 30 characters and mapping body copy into description lines. The TikTok adapter requires a full-screen video, so it flags the vertical image for creative team review and pauses that platform's deployment while launching the others.
Interview question
Which architecture best insulates a cross-platform ad system's core campaign model from external API volatility and schema drift?
- a.Replicate each platform's object hierarchy into a unified relational schema that all services query and update directly
- b.Allow marketers to design campaigns directly against each platform's native schema and route requests through an API gateway
- c.Maintain a platform-agnostic canonical model, use provider-specific adapters to transform into native schemas, and deploy asynchronously with validationCorrect
- d.Persist all campaign data in a single table with nullable columns for every platform field and invoke APIs synchronously on save
Why? this is the answer
A canonical model captures marketing intent without referencing any provider schema, while adapters isolate platform-specific mappings and constraints, and an async pipeline handles partial failure gracefully. Option D is wrong because a single sparse table tightly couples the system to every platform's fields and synchronous calls block users and eliminate failure isolation.
Just read this? Test yourself on what you have been reading.
Read the original → unified.to
- #system-design
- #advertising
- #data-modeling
- #api-integration
- #platform-adapters
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on system-design — each one lists the topics its interview covers.
See open roles