Netflix Java Developer Interview Questions & Answers

At a high level, this system must decide how often a user can see an ad and which ad comes next. The main challenge is keeping that decision fast while the delivery state keeps changing. I would explain it in three flows: the request path, the state lookup path, and the background update path. Reads use a Hot State Cache first, while delivery events update durable state later. The trade-off is that cached state can become stale, so freshness checks and conservative decisions are important.

The system must quickly decide whether a user can receive another ad and which ad should come next. Every delivery changes the user's frequency count and delivery order. Requests still need to stay fast under load. The diagram separates the work into a fast request path and a background update path. The request path reads rules and current state, then returns a decision. The background path records deliveries, updates saved state, and keeps the cache fresh.

1. Should frequency limits be tracked per user, per household, or both?
2. How fresh must the frequency and order state be before serving an ad?
3. What should happen when the cache or current-state store is temporarily unavailable?

I would say that an ad request first goes to the API / Edge. It handles Authentication, Validation, and Rate Limiting. Then it forwards the request to the Java Ad Frequency & Order Tracking Service.

The Java service is stateless across separate JVM replicas. Each JVM Replica runs Java 21/25 and contains a Request Handler, Eligibility / Order Engine, and Response Builder. Virtual Threads can help while waiting on blocking I/O. Separate JVM replicas do not share memory, so shared state stays outside them.

The service reads the Campaign Rules / Config Store for frequency caps, delivery order rules, and creative pools. It then checks the Hot State Cache first.

The cache stores state by user or household plus campaign. That includes count, next order, version, and timestamp. Cache-first reads keep requests fast.

If the cache misses or the entry is stale, the service reads the Durable Current-State Store. This store keeps materialized current state, meaning the useful counters and order values are already prepared. The service does not scan raw delivery events on each request.

The Eligibility / Order Engine uses the rules and current state. It checks the frequency cap and decides the next ad order.

The Response Builder creates the ad decision. The Java service sends that result back through the API / Edge to the Client / Ad Request Source.

After delivery or acknowledgement, the Java service writes a Delivery Event to the append-only Event Log / Queue. The queue is partitioned by user or household plus campaign.

The replicated Java Consumer / Updater Service reads those events. It performs idempotent per-key updates, meaning retries do not apply the same state change twice. It updates the Durable Current-State Store, then refreshes or invalidates the Hot State Cache.

The stored state carries a version or timestamp so the service can judge freshness. If the cache is unavailable, the service reads the current-state store. If freshness is uncertain, the engine makes a conservative cap or order decision.

Failed background processing goes to the Retry Queue with backoff. After retries are exhausted, the event moves to the Dead Letter Queue. Metrics, Logs, and Traces watch latency, cache hit rate, errors, queue lag, retries, and end-to-end behavior.

The trade-off is speed versus freshness. Caching keeps reads fast, but stale state must be handled carefully.

At a high level, the goal is to keep one in-memory key-value store correct when many threads use it at the same time. The main challenge is allowing fast reads without letting writes corrupt shared data. I would explain the read path, the write path, and how keys are routed to shards. Each shard has its own HashMap and ReadWriteLock, so different shards can work in parallel. The trade-off is that hot keys can still create contention, and a JVM crash loses the in-memory data.

The system must store key-value pairs in memory and stay correct when many threads use it at the same time. The hard part is shared data. Two threads may touch the same key almost together, so reads and writes need clear safety rules. The diagram solves this by splitting the store into shards. A key is hashed to one shard. Each shard has its own HashMap and ReadWriteLock. This keeps locking local and lets unrelated shards work in parallel.

1. Is this store only inside one JVM, or must data be shared across processes?
2. Must data survive a JVM crash, or is in-memory loss acceptable?
3. Are get, put, and delete enough, or do we need multi-key operations?

I would keep the store inside one JVM and split the data into several shards. A shard is one smaller part of the key space. Reader and writer threads enter through the Public API. It supports get(key), put(key, value), and delete(key). The Request Router runs hash(key) and chooses the shard.

I avoid one global lock around the whole store. A global lock would make unrelated keys wait. Sharding keeps most locking inside one shard.

For a read, the client sends a GET request to the Public API. The Request Router hashes the key and sends it to one shard. That shard acquires its read lock and reads the value from its HashMap.

Multiple readers can hold a shard's read lock together when no writer holds its write lock. Reads on different shards can also run together. The value, or a not-found result, returns through the API to the reader thread.

For put or delete, the router hashes the key and selects one shard. That shard acquires its write lock before changing the HashMap.

The write lock gives one writer exclusive access to that shard during the change. Other shards can continue serving reads and writes. After the map changes, the lock is released and an acknowledgement returns to the writer thread.

The key rule is that each lock protects one shard, not the whole store. This reduces contention because unrelated keys often use different locks. Lock and unlock also give safe visibility between threads. A later thread that acquires the lock sees changes made before the earlier thread released it.

A hot key or hot shard is still a weak point. Many requests mapped there compete for the same lock. A writer also blocks readers on that shard while it holds the write lock.

I would stress test the store with ExecutorService or virtual threads. I would mix get, put, and delete calls and look for races. I would also run linearizability checks, meaning completed operations should look as if they happened in one valid order.

I would test hot shards, contention, starvation risk, and process crashes. Metrics and logs help show lock pressure. The main failure limit is durability. If the JVM crashes, the in-memory data is lost because this design has no persistent storage.

At a high level, the goal is to spread campaign delivery across its full time window without spending the budget too early. The hard part is making fast decisions while many ad requests arrive at once. I would explain the design in three flows: campaign setup, real-time pacing decisions, and background delivery tracking. The Pacing Decision Service uses cached settings, counters, traffic forecasts, and an atomic budget reservation before serving. The main trade-off is that fast counters may be slightly approximate, while the Budget Ledger / Reservation Store protects exact spending.

The goal is to spend each campaign budget gradually instead of using too much money early. This is difficult because traffic can rise or fall quickly, and many ad requests can arrive at the same time. Each pacing decision must be fast, but concurrent requests must not spend the same remaining budget. The design separates campaign setup from the runtime path. The Pacing Decision Service makes fast delivery decisions. Background processing records what was actually delivered and keeps counters and committed spending aligned.

1. Should pacing aim for a smooth delivery curve, or can campaigns catch up later?
2. How strict must the system be about never spending above the campaign budget?
3. How fresh do traffic forecasts and delivery counters need to be?

For campaign setup, the Advertiser / Campaign Manager UI sends create or update requests through the API Gateway / Auth / Validation / Rate Limits layer. The Campaign Management Service then saves budget, start and end time, targeting, pacing mode, and caps in the Campaign Config Store.

The Campaign Management Service also warms or updates the Config Cache inside the Pacing Decision Service. This cache keeps campaign settings close to the fast request path.

For runtime delivery, an Ad Request / Auction Path reaches the Ad Server / Auction Service. That service calls the Pacing Decision Service.

Each Java service replica has its own JVM-local Config Cache. Replicas do not share that memory. The Pace Controller uses remaining budget, remaining time, current spend, and the Forecast / Traffic Model. It calculates a target spend rate and applies smooth pacing, catch-up, or slow-down adjustments.

The service also reads the Real-Time Counters Store for recent spend, impressions, and clicks. These counters are fast enough for the decision path.

Before serving an ad, Token / Budget Reservation reserves budget in the strongly consistent Budget Ledger / Reservation Store. The reservation uses a compare-and-swap or conditional update, so competing requests cannot reserve the same budget.

Throttle / Bid Multiplier Logic then decides whether to allow or throttle the request and returns a pacing factor to the Ad Server / Auction Service. The key rule is to reserve before serving.

If the ad is served, the Ad Server / Auction Service sends an impression, click, or spend event to the Event Stream / Queue. The Delivery Event Consumer / Aggregator consumes these events at least once.

It removes duplicate effects, updates the Real-Time Counters Store, and commits or releases the reservation in the Budget Ledger / Reservation Store. This background path keeps event processing away from the main pacing response.

When traffic changes, the Pace Controller adjusts throttling using recent forecasts and guardrails. If the forecast becomes stale, the diagram uses conservative throttling instead of taking more spending risk.

The scheduled Reconciliation Job compares billing or event data with the counters and ledger. It detects drift, corrects or backfills data, and raises alerts.

Observability collects metrics, logs, traces, and alerts. It tracks delivery rate, pacing error, overspend risk, consumer lag, reservation failures, and forecast drift. The main trade-off is that counters may have small short-term error, but overspending is not acceptable.

At a high level, this system lets publisher teams change configuration rules safely without slowing down serving traffic. The main challenge is making rule updates correct while keeping rule reads fast across many JVMs. I would explain it in three flows: creating and publishing a version, spreading that version to caches and serving services, and rolling back safely. The design uses versioned rules, immutable snapshots, an active-version pointer, and local caches. The trade-off is that serving JVMs may switch versions at slightly different times during background propagation.

The system lets publisher teams create rules for many properties, review them, publish a safe version, and quickly undo a bad change. The hard part is keeping rule changes controlled while serving systems need very fast reads. Many Java JVMs must move to the correct version without stopping traffic. The diagram solves this with a controlled write path, a background propagation path, a fast cached read path, and a rollback path.

1. Can one publisher have many properties with different rules?
2. How quickly must a published version reach serving services?
3. Is a short period with different versions across JVMs acceptable?
4. Do rule changes require approval before publishing?
5. How long should old versions remain available for rollback?

For the write path, the Publisher Operations Admin UI sends an HTTPS create or update request to the API Gateway / Edge. The gateway handles authentication, RBAC authorization, and rate limiting. It then sends the request to the Config Management Service Cluster, which runs as Java 21/25 stateless replicas in separate JVMs.

The Rule Validator checks schema, business rules, conflicts, and property ownership. A valid change is saved as a draft in the Versioned Rule Store. The Version Manager tracks versions, concurrency control, metadata, and publisher/property scope.

The Publish Controller coordinates publishing. The Rule Snapshot Builder computes the effective rule set for that publisher and property, including inheritance, defaults, overrides, and constraints.

The snapshot is immutable, meaning it is not changed after publishing. Its metadata is saved, and active_version moves to the selected version. The Publish Controller writes an append-only Audit Log / Change History record and sends a ConfigVersionPublished event to the Event Bus.

The Event Bus sends the version event to Propagation Workers in separate Java consumer JVMs. They warm or invalidate the Distributed Config Cache and notify serving systems to refresh. They retry failed refresh work with backoff.

This work is asynchronous, meaning publishing does not wait for every serving JVM. The downside is that JVMs may briefly use different versions.

Serving / Decisioning Services keep effective rules in a Local In-Memory Cache keyed by publisher, property, and version. This is the normal fast path.

When a serving JVM needs a snapshot that is not local, it asks the Runtime Config Read Service. That service checks the Distributed Config Cache first. On a miss, it reads the active snapshot from the Versioned Rule Store. It returns the rules with the version, and the serving JVM refreshes its local cache.

For rollback, the operator selects a known-good version. The system resets active_version and republishes the version event. Caches and serving JVMs refresh back to that version. If refresh fails, serving keeps the last known-good configuration.

The write-side version activation is strongly consistent. Background propagation is eventually consistent, meaning some JVMs can lag briefly. Metrics, logs, tracing, and alerts watch publish failures, propagation lag, cache misses, error rates, and store failures.

At a high level, the goal is to keep demand-side ad data organized and easy to query. The main challenge is supporting management writes, fast eligibility joins, and reporting without mixing everything into one large table. I would explain three flows: campaign management, ad eligibility, and reporting. The schema stays normalized with bridge tables for many-to-many targeting. Event facts are stored separately for reporting and backfill work. The trade-off is more joins, but we gain clearer data rules and safer schema changes.

The goal is to store advertiser, campaign, targeting, creative, and ad-event data in a clean structure. The difficult part is that the same data supports different jobs. Campaign managers change configuration. Ad serving must quickly find eligible ads. Reporting must process many impression, click, and conversion records. The diagram handles this by keeping management data normalized, using bridge tables for targeting relationships, and keeping reporting events in separate fact tables. The Java service then uses different query paths for each job.

1. Which eligibility filters are used most often during ad serving?
2. How much reporting history must remain available?
3. Can campaign and targeting changes take effect immediately?

I would first model the business hierarchy clearly. An advertiser has many campaigns, and each campaign has many line items. A line item contains bidding, budget, date, status, and version fields.

Creatives belong to advertisers. A creative can have many creative assets. A line item can use many creatives, so line_item_creative connects them with a composite primary key.

This keeps repeated data out of the main tables and gives each table one clear job.

For targeting, one line item may match many audience segments, geographies, device types, inventory sources, or deals. Each of those values may also be used by many line items.

I would therefore use bridge tables such as line_item_segment_target and line_item_geo_target. Each bridge uses both IDs as its primary key. A reverse index, such as (segment_id, line_item_id), also helps queries that start from the target value.

inventory_source has many deals, so deal stores its inventory_source_id foreign key.

For campaign management, the Campaign Manager UI sends an HTTPS request to the Java 21/25 DSP Service. Campaign Management runs SQL INSERT, UPDATE, and SELECT operations across advertiser, campaign, line item, creative, and targeting tables. The service then returns the HTTPS response.

For ad serving, the Ad Serving / Eligibility API sends an HTTPS request to Targeting & Eligibility Query. That path filters active line items by status, dates, and budget. It then intersects the targeting bridge tables and joins through line_item_creative to find creatives. The service returns the eligible ads response.

Indexes on campaign and line-item status and date fields make these common filters cheaper.

I would keep high-volume event records outside the normalized management tables. impression_event records the line item, creative, request, event time, and spend. click_event and conversion_event reference the impression.

Reporting / Backfill Jobs submit asynchronous jobs to the service and receive job status or results. Inside the service, Reporting / Backfill Jobs run aggregate SQL over the event tables and join back to line items and campaigns. This background path does not block the normal eligibility response.

The impression table can be partitioned by event date and indexed by (line_item_id, event_time). Its (request_id, line_item_id) pair is unique. Click and conversion tables are indexed by impression_id.

Foreign keys protect relationships. NOT NULL, UNIQUE, and CHECK rules prevent invalid rows. Status values use controlled checks, time values use UTC, and money uses minor units such as cents.

The version field on line_item supports optimistic locking. This means an update can detect that another request changed the same row first. Threads or virtual threads inside one JVM may share mutable state, so that shared state must be thread-safe. Separate JVM replicas do not share the same heap.

For schema changes, I would use expand, dual write or backfill, switch reads, and then contract. I would also prefer status-based soft deletes instead of destructive deletes when audit history matters.

At a high level, the goal is to keep direct-sold DSP orders correct while many users and downstream systems depend on them. The main challenge is that order updates must be safe, while activation, billing, notifications, and reporting should not slow the user request. I would explain three flows: the synchronous create or update path, the order lifecycle, and the background event path. The relational Orders DB is the source of truth. The trade-off is extra event, audit, and retry machinery.

The system must store direct-sold advertising orders and keep every change correct. Each order belongs to an advertiser, optional agency, and sales contract. An order can contain many line items with budgets, schedules, pricing, targeting, inventory, and creatives. The hard part is that people may edit orders while several downstream systems need those changes. The diagram keeps the core write controlled, then sends background events after a successful commit.

1. Can several users edit the same order at the same time?
2. Which state changes need approval?
3. How quickly must DSP activation receive an order change?
4. Can reporting appear a little later?

I would make DSP Order the aggregate root, meaning it controls the main order rules.

Advertiser, Agency, and Sales Contract or Insertion Order can each relate to many DSP Orders. Each order has many Line Items or Flights. A line item connects to Budget, Schedule or Flight Dates, Pricing, Pacing Rules, Targeting Profile, Inventory or Deal, and Creative Assignment. Creative Assignment connects to one or more Creatives.

For the write path, Sales Ops uses the Internal Order UI. The request crosses the API, authentication, authorization, and validation boundary. It also checks an idempotency key, which helps recognize the same request sent again.

The request enters the Java 21/25 Order Service inside the JVM. The Business Rules and State Transition Validator checks limits and state changes. The Order Aggregate Manager loads the order, applies the change, and checks the version.

The service saves the core change in one ACID transaction, so important database changes succeed or fail together. The transactional Orders DB is the source of truth. After the save succeeds, the service returns the updated order and status.

I would use optimistic locking with the version field. If another user saved a newer version first, the stale update is rejected instead of overwriting newer data.

The lifecycle is Draft, Pending Approval, Approved, Scheduled, Active, Paused, and Completed. Rejected and Cancelled are side outcomes. Every allowed state change writes Status History and an Audit Log or Version Record.

After a successful commit, the Outbox or Change Events flow sends OrderCreated, OrderUpdated, StatusChanged, and OrderCancelled events to the Event Bus or Queue.

Consumers handle Trafficking or DSP Activation Sync, Inventory Forecasting or Availability, Billing and Finance, Notifications or Approval Workflow, and Reporting Ingestion. They are idempotent, meaning a repeated event should not repeat the business action.

Failed messages use retry and backoff. Messages that still fail can move to the DLQ for safe reprocessing.

A Stream Processor or ETL flow builds Analytics Warehouse or Reporting Facts from events. These records are denormalized, meaning useful values are stored together for faster analysis.

Reports use advertiser, contract, order, line item, creative, and date. Metrics include budget, spend, impressions, clicks, conversions, CTR, viewability, and pacing.

Read Models or Materialized Views support dashboards without slowing writes. Soft-delete or retention rules keep history. The trade-off is more background infrastructure, but core order writes stay controlled.