Netflix·Software Engineer·Onsite - System Design / Architecture·Senior

Senior

Jul 2026

Summary

Netflix system design round for a software engineer role, focused entirely on building a relational data model for a demand-side ad platform. Dense question with a lot of moving parts, and I felt like I was playing catch-up the whole time.

Questions Asked (1)

Design a normalized relational schema for a demand-side advertising platform, covering advertisers, campaigns, ad groups, and creatives, along with targeting, budgeting, pacing, scheduling, and status fields. Also explain how you'd structure reporting join keys to trace impressions and clicks back up the hierarchy.

Data ModelingSystem DesignTechnical Trade-offs

Author's notes

This one sprawled in a way I didn't expect.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by outlining the core entities (advertiser, campaign, ad group, creative) and their relationships, then layer on targeting, budgeting, pacing, scheduling, and status as attributes or related tables. For reporting, design a fact table with foreign keys to each level of the hierarchy, and explain how to denormalize for query performance while maintaining traceability.

Pro tip: Emphasize that while normalization reduces redundancy, reporting often benefits from a star schema with a denormalized dimension for the hierarchy to avoid costly joins. Mention that Netflix's scale demands careful consideration of partitioning and indexing strategies.

1. Identify core entities and relationships

List the main entities: Advertiser, Campaign, AdGroup, Creative. Define one-to-many relationships: Advertiser has many Campaigns, Campaign has many AdGroups, AdGroup has many Creatives.

2. Define attributes for each entity

For each entity, specify key attributes: Advertiser (id, name, contact info), Campaign (id, advertiser_id, name, budget, start_date, end_date, status), AdGroup (id, campaign_id, name, bid, targeting_criteria, budget, pacing, schedule, status), Creative (id, ad_group_id, format, content, status).

3. Model targeting, budgeting, pacing, and scheduling

Decide whether to store targeting as JSON or separate tables (e.g., targeting_criteria with key-value pairs). Budgeting can be at campaign and ad group levels; pacing as a strategy (even, ASAP) with related fields; scheduling as start/end dates and dayparting.

4. Design reporting fact table and join keys

Create a fact table for impressions and clicks with foreign keys to advertiser, campaign, ad group, and creative. Include a timestamp and other metrics. Explain that you might denormalize the hierarchy into a single dimension table for faster queries.

5. Discuss trade-offs and scalability

Address normalization vs. performance: normalized for OLTP, denormalized for OLAP. Mention partitioning by date, indexing on foreign keys, and potential use of columnar storage for reporting.

Key Points to Mention

Use of surrogate keys for each entity to ensure uniqueness and simplify joins.
Targeting can be complex; consider a flexible schema (e.g., JSON) or an entity-attribute-value model for dynamic criteria.
Budget and pacing fields: total budget, daily budget, spend, pacing algorithm (e.g., even, aggressive).
Scheduling: start and end dates, dayparting (time-of-day targeting), and time zone considerations.
Status fields: active, paused, archived, etc., at each level to control delivery.
Reporting: fact table with foreign keys to all levels, and possibly a denormalized dimension for the hierarchy to optimize query performance.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.