PracHub
QuestionsCoachesLearningGuidesInterview Prep
|Home/System Design/Netflix

Model advertiser intake database schema

Last updated: Apr 19, 2026

Quick Overview

Model advertiser intake database schema evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

  • hard
  • Netflix
  • System Design
  • Software Engineer

Model advertiser intake database schema

Company: Netflix

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Design the data model for an advertiser intake system (similar in spirit to an F1-backed schema). Identify core entities—organization, account, user/seat, campaign, ad group, creative, budget/flight, targeting, frequency-cap policy, billing, approvals—and define key fields and relationships. Provide ERD-level tables with primary/foreign keys; discuss normalization vs denormalization, multi-tenancy and row-level security, configuration versioning and auditability, soft deletes, idempotent imports, and how the schema supports validation and partial onboarding.

Quick Answer: Model advertiser intake database schema evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Related Interview Questions

  • Design Ad Frequency and Order Tracking - Netflix
  • Design Rolling-Window Ad Frequency Capping - Netflix (medium)
  • Design ad frequency capping - Netflix (medium)
  • Design a File Backup System - Netflix (hard)
  • Design an Ad Pacing System - Netflix (hard)
|Home/System Design/Netflix

Model advertiser intake database schema

Netflix logo
Netflix
Jul 17, 2025, 12:00 AM
hardSoftware EngineerOnsiteSystem Design
16
0

Model advertiser intake database schema

Advertiser Intake and Campaign Data Model (F1-style)

Context

You are designing a multi-tenant advertiser intake and campaign configuration system. The system must cleanly model advertisers and their campaigns, enable hierarchical configuration (organization → account → campaign → ad group → creative), and support operational needs such as approvals, auditability, and billing. The schema should be amenable to an F1/Spanner-style hierarchical layout (composite keys, parent-child locality), but also work in a standard RDBMS.

Requirements

  • Model core entities and relationships:
    • Organization, account, user/seat (and account membership/roles)
    • Campaign, ad group, creative (with assets)
    • Budget and flighting (by campaign/ad group as applicable)
    • Targeting (geo, device, audience, exclusions, etc.)
    • Frequency-cap policy (campaign/ad group scope)
    • Billing (billing profile, invoices, invoice lines, spend ledger)
    • Approvals (for onboarding and configuration changes)
  • Provide ERD-level tables with primary/foreign keys and key fields.
  • Discuss:
    • Normalization vs. denormalization (read/write trade-offs)
    • Multi-tenancy and row-level security
    • Configuration versioning and auditability
    • Soft deletes
    • Idempotent imports
    • How the schema supports validation and partial onboarding (drafts, checklists)

Deliverables

  • ERD-level table definitions (names, primary keys, foreign keys, key columns) in a hierarchical, F1-friendly fashion (composite keys) or an equivalent approach for a traditional RDBMS.
  • A brief rationale for key design decisions and operational considerations.

Constraints & Assumptions

  • Preserve the scope, facts, inputs, and requested outputs from the prompt above.
  • If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
  • Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers

  • A scoped requirements summary with concrete non-goals and success metrics.
  • API, data model, architecture, consistency, capacity, and operations.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Netflix•More Software Engineer•Netflix Software Engineer•Netflix System Design•Software Engineer System Design

Your design canvas — auto-saved

PracHub

Master your tech interviews with 8,000+ real questions from top companies.

Product

  • Questions
  • Learning Tracks
  • Interview Guides
  • Resources
  • Premium
  • For Universities
  • Student Access

Browse

  • By Company
  • By Role
  • By Category
  • Topic Hubs
  • SQL Questions
  • AI Coding Questions
  • Compare Platforms
  • Discord Community

Support

  • support@prachub.com
  • (916) 541-4762

Legal

  • Privacy Policy
  • Terms of Service
  • About Us

© 2026 PracHub. All rights reserved.