Model advertiser intake database schema

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.

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.

|Home/System Design/Netflix
Netflix logo
Netflix
Jul 17, 2025, 12:00 AM
hardSoftware EngineerOnsiteSystem Design
19
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.

Clarifying Questions to Ask Guidance

  • 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 Guidance

  • 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 Guidance

  • 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...