Netflix Python Developer Interview Questions & Answers

I would use one depth-first search starting from the CEO at level 0. When I enter an employee, I record the current depth as the level and increase that level’s histogram count. When the recursive calls return, I calculate the employee’s subtree size. The number below is subtree size minus one. If it equals the depth, the employee is balanced. Every employee is visited once, so the time complexity is O(n), and the auxiliary space complexity is O(n).

The input is a rooted organization tree. We need to calculate each employee’s level, find employees whose number of managers above equals their number of descendants below, and count how many employees appear at each level. A depth-first search fits this problem because depth is available while moving down the tree, while subtree size is available when the recursive calls return.

1. What input sizes, value ranges, and edge cases should the solution handle?
2. What output should be returned for empty, invalid, or duplicate input?
3. Should I prioritize execution time or memory use, and may I use the standard library?

The organization chart is stored as an adjacency list. Each employee maps to a list of direct reports.

For the example:

CEO -> [CTO, CFO, COO] CTO -> [Dev1] CFO -> [Fin1] COO -> [Ops1] Dev1 -> [] Fin1 -> [] Ops1 -> []

The CEO is the root.

The level of an employee is the number of managers above that employee. The CEO has level

1. CTO, CFO, and COO have level
2. Dev1, Fin1, and Ops1 have level 2.

The number below an employee means the number of descendants in that employee’s subtree. If subtree_size includes the employee, then descendants equals subtree_size minus one.

An employee is balanced when:

depth == subtree_size - 1

The function returns a map of employee levels, a list of balanced employees, and a histogram that maps each level to its employee count.

I call DFS with the CEO and depth 0.

When DFS enters an employee, it records the employee’s level and increases the histogram count for that level.

It then visits every direct report with depth plus one.

When all child calls return, DFS adds their subtree sizes and includes the current employee. This gives the exact subtree size for the current employee.

The levels map starts as an empty dictionary. It stores employee name to level.

The histogram starts empty. It stores level to employee count.

The balanced list starts empty. It stores employees that pass the balance condition.

The traversal starts at CEO with depth 0.

The main invariant is: after DFS returns from an employee, the returned subtree size is correct for that employee, and every employee in that subtree has already been processed.

Step 1: Enter CEO at depth 0. Record CEO: 0. The histogram becomes {0: 1}.

Step 2: Enter CTO at depth 1. Record CTO: 1. The histogram becomes {0: 1, 1: 1}.

Step 3: Enter Dev1 at depth 2. Record Dev1: 2. The histogram becomes {0: 1, 1: 1, 2: 1}. Dev1 has no reports, so its subtree size is 1. Its descendant count is 0. Depth 2 does not equal 0, so Dev1 is not balanced.

Step 4: Return to CTO. CTO’s subtree contains CTO and Dev1, so its subtree size is 2. Its descendant count is 1. Its depth is also 1, so CTO is balanced.

Step 5: Enter CFO at depth 1. Record CFO: 1. The histogram becomes {0: 1, 1: 2, 2: 1}.

Step 6: Enter Fin1 at depth 2. Record Fin1: 2. The histogram becomes {0: 1, 1: 2, 2: 2}. Fin1 has subtree size 1 and 0 descendants. Depth 2 does not equal 0, so Fin1 is not balanced.

Step 7: Return to CFO. CFO has subtree size 2 and 1 descendant. Its depth is 1, so CFO is balanced.

Step 8: Enter COO at depth 1. Record COO: 1. The histogram becomes {0: 1, 1: 3, 2: 2}.

Step 9: Enter Ops1 at depth 2. Record Ops1: 2. The histogram becomes {0: 1, 1: 3, 2: 3}. Ops1 has subtree size 1 and 0 descendants. Depth 2 does not equal 0, so Ops1 is not balanced.

Step 10: Return to COO. COO has subtree size 2 and 1 descendant. Its depth is 1, so COO is balanced.

Step 11: Return to CEO. The CEO’s subtree contains all 7 employees. The CEO therefore has 6 descendants. Its depth is 0, so the CEO is not balanced.

The final result is:

levels = {CEO: 0, CTO: 1, CFO: 1, COO: 1, Dev1: 2, Fin1: 2, Ops1: 2}

balanced = [CTO, CFO, COO]

histogram = {0: 1, 1: 3, 2: 3}

The depth passed into DFS is exactly the number of managers above the current employee.

The subtree size returned by DFS includes the current employee and every descendant. Subtracting one removes the current employee and gives the exact number of descendants below.

Therefore, depth == subtree_size - 1 correctly identifies balanced employees.

The histogram is correct because every employee increases exactly one bucket for the employee’s level.

The outer function creates the levels dictionary, histogram, and balanced list.

The nested dfs function receives an employee and that employee’s depth. It records the level and histogram count before visiting direct reports.

It starts subtree_size at 1 because the subtree contains the current employee. Each recursive child call returns a child subtree size, which is added to the total.

After all children return, the code calculates descendants as subtree_size - 1. It adds the employee to balanced when descendants equals depth. It then returns the subtree size to the parent.

After DFS finishes, the code returns the levels map, balanced list, and histogram sorted by level.

Let n be the number of employees. Each employee is entered once and returned from once. Therefore, the time complexity is O(n).

The auxiliary space complexity is O(n). The levels map, histogram, balanced list, and recursion stack can grow with the number of employees.

Relevant edge cases are a single-employee tree, a skewed tree, employees with no reports, and employees represented by empty child lists. A single CEO has depth 0 and 0 descendants, so that CEO is balanced under the same rule.

The key insight is that the two values used by the balance test become available at different parts of one DFS. The employee’s depth is known when DFS enters the node, so it gives the number of managers above. The employee’s subtree size is known after all child calls return, so subtree_size - 1 gives the number of descendants below. The invariant is that when DFS returns from a node, its complete subtree has been processed and its returned subtree size is correct. This lets one traversal produce all three required outputs.

Let n be the number of employees. The time complexity is O(n) because DFS visits each employee once and processes each reporting relationship once. The auxiliary space complexity is O(n). The levels dictionary can hold n entries. The balanced list can contain up to n employees. The histogram can contain up to n level entries. The recursion stack can also grow to n when the organization tree is completely skewed.

A common mistake is counting only direct reports instead of all descendants. Another mistake is comparing depth with subtree size without subtracting the current employee. Some candidates check the balance condition before all child calls return, when the final subtree size is still unknown. Others forget to update the histogram on every node entry. It is also incorrect to claim O(1) auxiliary space because the result structures and recursion stack can grow with the tree.

Explain the solution with one sentence before coding: depth gives the number above, and subtree size minus one gives the number below. Then show that DFS provides both values in one traversal.

I use a size-limited max heap to keep the k closest points seen so far. Python heapq is a min heap, so I store each squared distance as a negative value. For every point, I compute x * x + y * y, push the negative distance with the point, and pop when the heap grows beyond k. This removes the farthest candidate. The solution takes O(n log k) time and O(k) auxiliary space.

The problem gives a list of points in a two-dimensional plane and an integer k. We must return the k points closest to the origin, which is (0, 0). We compare squared distances, x² + y², because taking a square root would not change their order. A size-limited heap lets us keep only the best k points while processing the input.

1. What input sizes, value ranges, and edge cases should the solution handle?
2. What output should be returned for empty, invalid, or duplicate input?
3. Should I prioritize execution time or memory use, and may I use the standard library?

The input contains points in the form [x, y] and an integer k. The output contains point values, not indices.

For the example:

points = [[1, 3], [-2, 2], [4, 0], [0, 1]] k = 2

One valid output is:

[[-2, 2], [0, 1]]

The returned order does not matter.

We want to remove the farthest candidate whenever we have more than k points. A max heap is useful because its root represents the largest distance among the kept points.

Python heapq implements a min heap. To simulate a max heap, we store each squared distance as a negative value.

Each heap item has this form:

(-distance_sq, point)

A larger real distance becomes a smaller negative number. Therefore, heapq removes the farthest point first.

The invariant is that after each insertion and optional pop, the heap contains the closest min(k, processed points) points seen so far. When the heap contains k points, its root represents the farthest kept point.

Start with an empty heap:

max_heap = []

For each point [x, y], calculate:

distance_sq = x * x + y * y

Push (-distance_sq, [x, y]) into the heap.

If the heap size becomes greater than k, pop one item. The popped item is the farthest point among the current candidates.

For [1, 3], the squared distance is 1² + 3² = 10. Push (-10, [1, 3]). The heap contains one point.

For [-2, 2], the squared distance is (-2)² + 2² = 8. Push (-8, [-2, 2]). The heap now contains two points, so nothing is removed.

For [4, 0], the squared distance is 4² + 0² = 16. Push (-16, [4, 0]). The heap size becomes 3, which is greater than k. Pop once. The point [4, 0] is removed because its squared distance, 16, is the largest among the three candidates. The heap keeps [1, 3] and [-2, 2].

For [0, 1], the squared distance is 0² + 1² = 1. Push (-1, [0, 1]). The heap size again becomes 3. Pop once. The farthest kept point is [1, 3], with squared distance 10, so it is removed.

The final heap contains [-2, 2] and [0, 1]. Their squared distances are 8 and 1. These are the two smallest distances in the example.

After every insertion and optional pop, the heap contains the closest min(k, processed points) points seen so far.

If a new point is farther than the current kept set, that new point becomes the farthest candidate and is removed. If the new point is closer, the previous farthest kept point is removed instead.

After all points are processed, the heap contains the k closest points from the input.

The function returns an empty list when k is zero or negative. It then creates an empty heap and processes every input point.

For each point, it calculates the squared distance and pushes the negative distance with the point. If the heap grows beyond k, it pops once.

After the loop, it extracts and returns the point from every heap item. A heap is not a fully sorted structure, so the returned order may vary.

Each of the n points is pushed into a heap whose size is kept near k. A push or pop costs O(log k), so the total time is O(n log k).

The heap stores at most k points after trimming, so the auxiliary space is O(k).

Relevant edge cases include k = 0, k equal to or greater than the number of points, negative coordinates, duplicate points, and equal distances. If k is at least the number of points, all points are returned. When distances tie, any valid set of k closest points may be returned.

The key idea is to keep only the best k points instead of sorting all n points. The algorithm uses a size-limited max heap. Each entry stores (-distance_sq, point), where distance_sq is x * x + y * y. Python heapq is a min heap, so the negative distance makes the farthest real point appear at the root. After each push, the algorithm pops once if the heap size is greater than k. The invariant is that the heap contains the closest min(k, processed points) points seen so far.

Let n be the number of input points. The algorithm pushes every point into the heap and may pop one point after each push. Because the heap stays near size k, each push or pop takes O(log k) time. The total time is O(n log k). The heap stores at most k points after trimming, so the auxiliary space is O(k). Computing x * x + y * y takes O(1) time, and no square root is needed.

A common mistake is pushing positive distances into heapq. That creates a normal min heap and causes the closest point to be removed when the size exceeds k. Another mistake is forgetting to pop when the heap grows beyond k. Some candidates calculate square roots even though squared distances are enough. Others claim the heap output is sorted, but heap order is not fully sorted. It is also incorrect to claim that the displayed output order is the only valid order.

Explain the invariant before writing code: after every push and optional pop, the heap contains the closest min(k, processed points) points seen so far. This makes the reason for using negative distances and removing one point easy to defend.

I would model the prerequisites as a directed graph and use Kahn’s topological sort. I keep an indegree count for each task and a deque of tasks with no remaining prerequisites. For every task, I also track the largest finish time among its prerequisites. When its indegree becomes zero, I add its duration to that value. If I process all tasks, I return the finish times. Otherwise, there is a cycle. The time is O(n + m), with O(n + m) auxiliary space.

The problem gives task durations and directed prerequisite relationships. We must return the earliest finish time for every task. Tasks may run in parallel, so a task waits only for its slowest prerequisite. Kahn’s topological sort fits because it processes a task only after all of its prerequisites are known. A dynamic programming array stores the largest prerequisite finish time for each task.

1. What input sizes, value ranges, and edge cases should the solution handle?
2. What output should be returned for empty, invalid, or duplicate input?
3. Should I prioritize execution time or memory use, and may I use the standard library?

Each task is a node in a directed graph. An edge pre -> task means pre must finish before task can start.

The input contains:

• n, the number of tasks
• durations, where durations[i] is the time needed by task i
• prerequisites, where each pair is (pre, task)

The output is an array named finish. The value finish[i] is the earliest time when task i can finish.

For the example:

• n = 5
• durations = [3, 2, 4, 2, 1]
• prerequisites = [(0, 2), (1, 2), (1, 3), (2, 4), (3, 4)]

The result is [3, 2, 7, 4, 8].

I use Kahn’s topological sort. It uses an indegree count. The indegree of a task is the number of prerequisites that have not yet been removed.

I store the graph as an adjacency list. graph[pre] contains the tasks that depend directly on pre.

I also use max_prereq_finish. The value max_prereq_finish[t] is the largest finish time seen among the processed prerequisites of task t.

The central invariant is this: when a task is removed from the queue, its earliest finish time is final. Also, when a task’s indegree becomes zero, all of its prerequisite finish times have been considered.

The initial indegree array is [0, 0, 2, 1, 2].

Tasks 0 and 1 have indegree zero, so they can start at time zero. Their finish times are their own durations:

• finish[0] = 3
• finish[1] = 2

The initial queue is deque([0, 1]).

The initial finish array is [3, 2, 0, 0, 0].

The initial max_prereq_finish array is [0, 0, 0, 0, 0].

First, remove task 0 from the queue. Task 0 finishes at time 3 and points to task 2.

Update:

• max_prereq_finish[2] = 3
• indegree[2] changes from 2 to 1

Task 2 still has one remaining prerequisite, so it is not added to the queue.

The queue becomes [1]. The finish array remains [3, 2, 0, 0, 0].

Next, remove task 1. It points to tasks 2 and 3.

For task 2:

• max_prereq_finish[2] = max(3, 2) = 3
• indegree[2] changes from 1 to 0

All prerequisites of task 2 are now complete. Its earliest start time is 3. Its duration is 4, so:

• finish[2] = 3 + 4 = 7

Task 2 is added to the queue.

For task 3:

• max_prereq_finish[3] = 2
• indegree[3] changes from 1 to 0

Task 3 has duration 2, so:

• finish[3] = 2 + 2 = 4

Task 3 is added to the queue.

The queue becomes [2, 3]. The finish array becomes [3, 2, 7, 4, 0].

Next, remove task 2. It points to task 4.

Update:

• max_prereq_finish[4] = 7
• indegree[4] changes from 2 to 1

Task 4 still waits for task 3. The queue becomes [3]. The finish array remains [3, 2, 7, 4, 0].

Next, remove task 3. It also points to task 4.

Update:

• max_prereq_finish[4] = max(7, 4) = 7
• indegree[4] changes from 1 to 0

Task 4 can now start. Its earliest start time is 7, and its duration is 1:

• finish[4] = 7 + 1 = 8

Task 4 is added to the queue. The queue becomes [4]. The finish array becomes [3, 2, 7, 4, 8].

Finally, remove task 4. It has no outgoing edges. The queue becomes empty.

The final finish array is [3, 2, 7, 4, 8].

A task enters the queue only after every incoming edge has been removed. This means every prerequisite has already been processed.

Because prerequisites may run in parallel, the task does not wait for the sum of their finish times. It waits for the largest one. That largest value is the earliest legal start time for the task.

After the queue becomes empty, I compare the number of processed tasks with n. In this example, all 5 tasks were processed, so the graph is acyclic. If fewer than n tasks were processed, a cycle would be blocking the remaining tasks.

The code first builds the adjacency list and indegree array. It then places every indegree-zero task in a deque and sets its finish time to its duration.

The main loop removes one ready task at a time. For each dependent task, it updates the largest prerequisite finish time and decreases the indegree. When the indegree reaches zero, it calculates the dependent task’s finish time and adds it to the queue.

Each task is added to and removed from the queue once. Each prerequisite edge is processed once. Therefore, the time complexity is O(n + m), where n is the number of tasks and m is the number of prerequisite edges. The adjacency list, arrays, and queue use O(n + m) auxiliary space.

The key idea is to combine Kahn’s topological sort with dynamic programming on a directed graph. Topological sorting makes a task ready only after all of its prerequisites have been processed. For each task, max_prereq_finish[task] stores the largest finish time among its processed prerequisites. This value is the task’s earliest legal start time because prerequisites may run in parallel. When the task’s indegree becomes zero, its finish time is max_prereq_finish[task] + durations[task]. The invariant is that every task removed from the queue already has its final earliest finish time.

Let n be the number of tasks and m be the number of prerequisite edges. Building the graph takes O(n + m) time. During the topological traversal, each task is placed in the queue once, removed once, and each edge is examined once. The total time is O(n + m). The adjacency list uses O(n + m) memory. The indegree, finish, maximum-prerequisite-finish arrays, and queue use O(n) memory. Therefore, the auxiliary space is O(n + m).

A common mistake is to add all prerequisite finish times. That is wrong because prerequisites can run in parallel. The task waits for the maximum finish time, not the sum. Another mistake is calculating a task’s finish time before its indegree reaches zero. At that point, some prerequisite may still be missing. Candidates may also reverse the edge direction, forget to initialize indegree-zero tasks with their own durations, or return partial results without checking whether processed == n. It is also incorrect to claim O(n) time while ignoring the prerequisite edges.

State the invariant before coding: when a task enters the queue, every prerequisite has finished, and max_prereq_finish already contains its earliest legal start time. This makes the update rule and the cycle check easy to explain.

I would keep two structures for each key. One stores its timestamps in sorted order. The other maps each timestamp to its value. On put, I use bisect_left to insert the timestamp in the correct place or update an existing version. On get, I use bisect_right to find the newest timestamp that is less than or equal to the query time. Put is O(m) in the worst case, get is O(log m), and total auxiliary space is O(V).

This problem asks us to store several versions of the same key and return the newest version that existed at a requested time. Timestamps may arrive out of order. I keep the timestamps sorted for each key and use binary search to find the correct historical version.

1. What input sizes, value ranges, and edge cases should the solution handle?
2. What output should be returned for empty, invalid, or duplicate input?
3. Should I prioritize execution time or memory use, and may I use the standard library?

The store supports two operations.

put(key, value, timestamp) saves a value for one key at one timestamp.

get(key, timestamp) returns the value stored at the latest timestamp that is less than or equal to the requested timestamp.

If the key does not exist, or if every stored timestamp is later than the requested time, get returns an empty string.

I use two dictionaries.

timestamps[key] stores a sorted list of timestamps for that key.

values[key] stores another dictionary. It maps each timestamp to the value written at that time.

The central invariant is that timestamps[key] always stays sorted. Also, values[key][t] always stores the exact value written at timestamp t.

When a key appears for the first time, I create an empty timestamp list and an empty timestamp-to-value dictionary.

I use bisect_left to find the position where the timestamp belongs.

If that timestamp already exists, I update its value. I do not insert a duplicate timestamp.

If it does not exist, I insert it into the sorted list and store the value in the dictionary.

The first operation is put("volume", "low", 5).

The key does not exist yet. I create its structures. bisect_left([], 5) returns 0. I insert timestamp 5 and store "low".

The state becomes timestamps["volume"] = [5] and values["volume"] = {5: "low"}.

The second operation is put("volume", "high", 1).

The current timestamp list is [5]. bisect_left([5], 1) returns 0. I insert timestamp 1 before 5 and store "high".

The state becomes timestamps["volume"] = [1, 5]. The value map contains 1: "high" and 5: "low".

The third operation is put("volume", "mute", 8).

The current list is [1, 5]. bisect_left([1, 5], 8) returns 2. I insert timestamp 8 at the end and store "mute".

The timestamp list becomes [1, 5, 8].

The fourth operation is get("volume", 6).

bisect_right([1, 5, 8], 6) returns 2. This is the insertion position after all timestamps that are less than or equal to 6.

I subtract 1, so the predecessor index is 1. The timestamp at index 1 is 5. Timestamp 5 maps to "low".

The method returns "low".

For every key, its timestamp list is always sorted.

bisect_right returns the position after all timestamps that are less than or equal to the requested time.

The timestamp immediately before that position is therefore the latest valid version.

For query time 6, timestamp 8 is too new. Timestamp 5 is the latest valid timestamp, so the correct returned value is "low".

The put method uses bisect_left to find the exact sorted position of a timestamp. It checks whether the timestamp already exists. If it does, the method updates the stored value. Otherwise, it inserts the timestamp into the list.

The get method uses bisect_right and moves one position left. That gives the newest timestamp that does not exceed the query time.

Let m be the number of versions stored for one key.

Finding the position during put takes O(log m). Inserting into a Python list can shift up to m elements, so put takes O(m) in the worst case.

The get operation takes O(log m).

Python dictionary lookup and update are O(1) on average.

If V is the total number of stored versions across all keys, the auxiliary space is O(V).

Important edge cases are a missing key, a query before the first timestamp, an exact timestamp match, and a repeated put for the same key and timestamp.

The key insight is to separate timestamp ordering from value storage. For each key, a sorted list keeps all version timestamps in order. A second dictionary maps each timestamp to its exact value. The invariant is that timestamps[key] is always sorted and values[key][t] always contains the value written at time t. Because of this invariant, bisect_right can find the position after every timestamp that is less than or equal to the query. The predecessor is exactly the newest valid version.

Let m be the number of versions stored for one key. bisect_left finds an insertion position in O(log m) time. However, inserting into a Python list may shift up to m elements, so put takes O(m) in the worst case. If the timestamp already exists, updating the dictionary value is O(1) on average. get uses bisect_right and takes O(log m). Python dictionary lookup is O(1) on average. If V is the total number of stored versions across all keys, the auxiliary space is O(V).

A common mistake is appending timestamps without keeping them sorted. Binary search would then return the wrong position. Another mistake is using the result of bisect_right without subtracting one. Some candidates insert the same timestamp twice instead of updating its existing value. Others forget to return an empty string when the key is missing or when the query is earlier than the first timestamp. It is also incorrect to claim that put is O(log m), because inserting into a Python list can take O(m).

State the invariant before writing code: each key has a sorted timestamp list, and each stored timestamp maps to exactly one value. Then explain that bisect_right minus one returns the newest valid version.

At a high level, I would use one synchronous check before showing an ad. The Ad Server sends POST /v1/frequency-cap/check to the Frequency-Capping Service using mTLS and a JWT. The request contains the user, candidate ad, timestamp, and cap scopes. The service reads active rules and exposure counters, then returns a 200 OK eligibility decision with matched limits and remaining capacity. If the ad is shown, an impression event updates counters asynchronously. This keeps decisions fast, but recent impressions may take a short time to appear in the counters.

The API decides whether one candidate ad may be shown to one user. The main challenge is checking several cap scopes quickly while counting only real impressions. I would explain the synchronous decision first, then the asynchronous update path shown in the diagram.

1. Which clients and core use cases must the API support?
2. What authentication, authorization, and data-validation rules should I assume?
3. What scale, error handling, idempotency, and versioning requirements matter?

I would begin by saying that the Ad Server is the caller. The Frequency-Capping Service owns the eligibility decision.

The Ad Server calls POST /v1/frequency-cap/check. The connection uses mTLS and a JWT. mTLS encrypts the connection and verifies both services. The JWT carries the caller identity used for the service request.

The check happens before the candidate ad is shown. The later impression update is a separate flow.

The request contains requestId, userKey, and timestamp. It also contains the candidate ad identifiers.

The candidateAd object includes campaignId, lineItemId, creativeId, and categories[]. These values let the service check each relevant advertising level.

The request also contains scopesToCheck. The shown scopes are user, campaign, line item, creative, and category. This field tells the service which caps to evaluate.

The Frequency-Capping Service first validates the request. It then loads the cap definitions and reads the matching counters.

The service reads active rules from the Cap Rules Store. Example rules include ten impressions per user each day and four per campaign each day. Other examples include two per line item each hour, one per creative each day, and twenty per category each week.

The service also reads the Exposure Counter Store. Each counter represents a user, scope, entity, and time window. For example, u123+campaign42+2026-07-26 = 3 means that user has three counted exposures for that campaign during the daily window.

The service compares each current count with its matching limit. It evaluates the requested scopes before creating one final decision.

The Frequency-Capping Service sends a separate response back to the Ad Server. The diagram shows a 200 OK decision response.

The response contains eligible, which is either true or false. It also contains blockedScopes[] when one or more caps block the ad.

The matchedCaps[] list explains the evaluated caps. Each item contains the scope, entity ID, limit, current count, remaining capacity, and window. The response also includes a reasonCode and windowEndsAt.

This contract gives the Ad Server both the result and its reason.

The Frequency-Capping Service sends a decision log event to Decision Log / Analytics. This is a supporting flow, not part of the business response.

The log records the request ID, decision, blocked scopes, latency, and timestamp. It supports monitoring and analysis. It does not decide whether the ad is eligible.

The eligibility check does not increase exposure counters. A successful check does not prove that the ad was shown.

Only after the ad is shown does the Ad Server publish an impression event to the Impression Event Stream. The Counter Updater consumes that event.

The Counter Updater then increments the user, campaign, line-item, creative, and category counters in the Exposure Counter Store. This asynchronous path keeps the synchronous decision call fast.

If the check times out or returns an error, the Ad Server applies its configured fallback policy. A fail-open policy may show the ad. A fail-closed policy blocks it.

Fail-open protects ad delivery but may exceed a cap. Fail-closed protects cap enforcement but may block an eligible ad.

The asynchronous update path also creates a small delay. Two close requests may read the same old count before the newest impression event is processed. The benefit is lower decision latency and simpler request handling.

The benefit is a small and clear decision API. One request carries the user, candidate ad, timestamp, and cap scopes. One response explains the result and the matching limits. mTLS and JWT protect the service call, but they add certificate and token management work. Reading rules and counters during each check gives a useful decision, but it adds storage latency. Updating counters through events keeps the check fast and counts only shown ads. The downside is temporary counter delay. Two requests may see the same count before the newest impression is processed. The fallback policy also needs a business choice. Fail-open protects delivery but may break a cap. Fail-closed protects the cap but may block a valid ad.

At a high level, I would separate rule authoring from runtime delivery. Publishers use the Publisher Configuration API to create, update, retrieve, validate, version, and roll out rules. The API stores drafts in the Rule Store, creates immutable versions in the Version Catalog, and sends checks to the Validation Service. The Rollout Manager activates an approved version through the Runtime Config Service. Websites, mobile apps, channels, and ad inventory then fetch their specific rule JSON. OAuth2 tokens and JWT-protected HTTPS secure authoring. The trade-off is safer releases with more operational complexity.

The goal is to manage publisher-specific rules from editing through runtime delivery. The main challenge is preventing draft or invalid rules from becoming active. I would explain the design by following each request and response in the diagram.

1. Which clients and core use cases must the API support?
2. What authentication, authorization, and data-validation rules should I assume?
3. What scale, error handling, idempotency, and versioning requirements matter?

I would first separate the system into two main areas.

The Publisher Control Plane handles authoring, validation, storage, versions, auditing, and rollouts. The Runtime Delivery area serves active rules to applications.

A Publisher Admin can manage rules manually. An API Client or CI Pipeline can automate rule changes. Both use the same Publisher Configuration API, so the system keeps one consistent authoring contract.

This separation protects runtime consumers from unfinished draft changes.

The request first goes through the Identity Provider.

The Publisher Admin uses login with OAuth2 and receives a token. OAuth2 is a standard process for issuing access tokens. The API Client or CI Pipeline uses client credentials and receives a service token.

The clients then call the Publisher Configuration API over HTTPS with a JWT. A JWT is a signed token that carries the caller identity. The diagram shows the API returning rule payloads, status, or version information to the requesting client.

The identity flow is separate from the business rule flow.

The Publisher Configuration API is the main authoring entry point.

POST /publishers/{id}/rules creates a publisher-specific rule. PATCH /rules/{ruleId} updates an existing rule. GET /rules/{ruleId} retrieves one rule.

POST /rules/{ruleId}/validate validates the rule. GET /rules/{ruleId}/versions returns its versions. POST /rules/{ruleId}/rollouts starts a rollout.

The Publisher Admin uses these interfaces for direct changes. The API Client or CI Pipeline uses them for automation and bulk updates. The API returns the matching rule payload, status, or version information to the original caller.

Before activation, the Publisher Configuration API sends the rule to the Validation Service.

The validation request contains the schema, targeting information, and scope. The Validation Service returns a pass result, warnings, or errors.

Errors mean the rule should not move toward activation. Warnings tell the publisher that review may be needed. A passing result allows version creation and rollout to continue.

The API also saves and reads editable drafts through the Rule Store. The Rule Store returns the requested draft rule to the API.

This lets publishers revise a draft without changing an active version.

When a rule is ready, the Publisher Configuration API creates a version in the Version Catalog.

The Version Catalog stores immutable versions. Immutable means the stored version cannot be edited later. It also returns version history when the API requests it.

This provides a stable record of every approved rule state. A later rollout can therefore load an exact version instead of reading a changing draft.

The Publisher Configuration API also sends an audit event to the Audit Log. The Audit Log records the activity, but it does not produce the business response.

The Publisher Configuration API sends a rollout request to the Rollout Manager.

The request includes the environment, selected targets, and schedule. The Rollout Manager asks the Version Catalog to load the approved version. The Version Catalog returns the version payload.

The Rollout Manager then sends an activation and rollout event to the Runtime Config Service. Validation therefore happens before version activation. Rollouts can also be staged for selected targets and environments.

The benefit is controlled releases. The downside is additional rollout state and coordination.

The Runtime Config Service serves only active configuration.

The Website sends GET rules and receives website rules JSON. The Mobile App sends GET rules and receives mobile rules JSON. The Channel App receives channel rules JSON. The Ad Inventory Service receives ad rules JSON.

Each request and response is a separate flow. The runtime target sends the request. The Runtime Config Service sends the matching JSON response back.

This allows each publisher target to receive a different active rule set while sharing one controlled management process.

The benefit is strong separation between drafts, versions, rollouts, and active runtime rules. Publishers can edit a draft without changing production behavior. Validation catches bad schema, targeting, or scope before activation. Immutable versions make rollouts easier to review and trace. The Rollout Manager can release one approved version to selected targets and environments. JWT-protected HTTPS calls also protect the authoring interfaces. The downside is more operational work. The team must run the configuration API, validation service, stores, audit log, rollout manager, and runtime service. It must also keep rollout state and active versions consistent. We accept this complexity because configuration mistakes could affect websites, mobile apps, channels, and ad inventory at the same time.

At a high level, I would use one Campaign Intake API for creating and updating advertiser campaigns. The console sends a POST or PATCH request over HTTPS with a JWT. The payload includes campaigns, ad groups, creatives, targeting, budgets, dates, pacing, and the desired status. The API validates the request, stores creative references, and writes normalized campaign records. It then requests creative review and scheduling. Success returns IDs and current statuses. Invalid or unauthorized requests return clear errors. The trade-off is extra workflow complexity for safer validation and lifecycle control.

The goal is to accept a complete advertiser campaign through one clear interface. The main challenge is validating related resources while controlling review and status changes. I would explain the design by following the request and response paths shown in the diagram.

1. Which clients and core use cases must the API support?
2. What authentication, authorization, and data-validation rules should I assume?
3. What scale, error handling, idempotency, and versioning requirements matter?

I would begin with the advertiser using the Advertiser Console UI. The advertiser can create a campaign or edit an existing campaign.

The console first uses the Identity / Auth Service for login and account access. The service returns a JWT or session. A JWT is a signed token that identifies the logged-in advertiser.

The console then sends a POST or PATCH campaign payload over HTTPS with the JWT. HTTPS protects the request while it travels across the network.

The payload contains the campaign, ad groups, creatives, targeting, budgets, dates, pacing, and desired status. The diagram does not define a URL path. Therefore, I would describe this as a conceptual contract with the Campaign Intake API.

The Campaign Intake API sends the campaign data to the Validation & Policy Engine. This component checks both the data shape and the business rules.

Required fields must be present. The campaign needs at least one ad group and one creative. The start date must be earlier than the end date. The budget must be greater than zero.

Pacing must be DAILY or LIFETIME. Targeting values must be valid. Each creative needs a supported format and landing URL. The requested status transition must also be allowed.

The validation engine returns either an approved result or field errors. This prevents invalid campaign data from reaching storage and later workflows.

After validation succeeds, the API handles the main domain resources. These are Campaign, Ad Group, Creative, Targeting, and Budget & Schedule.

The API sends creative metadata and asset references to the Creative Asset Store. The store returns an asset ID after storage succeeds.

The API then inserts or updates normalized entities in the Campaign DB. Normalized means each resource type is stored separately instead of repeating the same data.

The database stores campaigns, ad_groups, creatives, targeting_rules, budget_schedule, and status_history. It returns IDs and persisted state to the Campaign Intake API.

After persistence, the API sends a campaign.created or review requested event to the Review & Status Workflow.

This workflow owns creative review and scheduling. A campaign starts in DRAFT. It may move to READY or PENDING_REVIEW. A review or policy failure may move it to REJECTED, which is terminal.

An approved campaign may become ACTIVE. An ACTIVE campaign may move to PAUSED and later return to ACTIVE. The scheduler activates the campaign at the start date and ends it at the end date.

The workflow also emits status updates. The stored campaign data includes status_history so lifecycle changes can remain traceable.

The Campaign Intake API returns the business response to the Advertiser Console UI. A successful creation returns 201 Created. A successful update returns 200. The response contains IDs and current statuses.

A 400 response means fields are malformed or missing. A 401 response means authentication is missing or invalid. A 403 response means the advertiser is authenticated but not allowed.

A 409 response means the request conflicts with the current state or duplicates another submission. A 422 response means the request is readable, but a business rule failed.

These separate errors help the console show a useful message to the advertiser.

The Campaign Intake API also sends audit events to the Audit Log. The log records intake events and important system actions. It supports compliance and debugging. It does not own the business response.

The main benefit is one controlled entry point for complex campaign data. Validation, asset storage, persistence, review, and scheduling have clear owners.

The trade-off is additional coordination. A campaign may be stored before review finishes. Therefore, a successful intake response does not always mean the campaign is already active.

The benefit is that one intake API gives advertisers a simple entry point. The API accepts the complete campaign structure and applies the same rules every time. HTTPS protects network traffic, while the JWT identifies the advertiser. Validation blocks invalid dates, budgets, pacing values, targeting, creatives, and status changes. Separate creative storage keeps asset handling apart from normalized campaign data. The Campaign DB keeps related entities and status history. The downside is more coordination between validation, asset storage, persistence, review, and scheduling. Review may finish after the original API response. Therefore, clients must use the returned status instead of assuming immediate activation. We accept this because controlled review and scheduled activation are safer than publishing every accepted request immediately.

At a high level, I would separate fast control requests from slower backup work. The client starts a job with POST /backups and receives a backupId and statusUrl. A Backup Agent scans files, creates chunks and checksums, and sends them through the Upload API. Workers store encrypted chunks and update progress. The client can list progress, retry failed work, restore files, and request an integrity report. HTTPS with JWT or mTLS protects client requests. The trade-off is more coordination, but queues and workers make long-running work scalable and recoverable.

The API manages long-running backups without making the client wait. The main challenge is separating quick control requests from slower upload, retry, restore, and analysis work. I would explain the design in the same order as the diagram.

1. Which clients and core use cases must the API support?
2. What authentication, authorization, and data-validation rules should I assume?
3. What scale, error handling, idempotency, and versioning requirements matter?

I would begin with the main control path. The Operator, App, or CLI sends POST /backups through HTTPS with JWT or mTLS. A JWT is a signed token that carries caller identity. mTLS encrypts traffic and lets both sides verify certificates.

The API Gateway and Auth component checks the caller. It then forwards the authenticated request to the Backup API. The Backup API asks the Backup Coordinator to create a backup session.

The coordinator writes the new backupId and queued state into the Metadata and Progress Store. It also enqueues the initial scan and upload work in the Retry Queue. The Backup API returns 201 Created with the backupId and statusUrl.

This response is quick because the backup continues asynchronously.

The Backup Agent reads the Source Files. It scans each file, splits it into chunks, and calculates a checksum. A checksum is a small value used to detect changed or damaged data.

The agent sends PUT /backups/{backupId}/chunks directly to the Upload API. The request contains the manifest delta and chunk data. The manifest records which files and chunks belong to the backup.

The Upload API validates the request and forwards valid chunks to an Upload Worker. The worker stores encrypted chunks in Object Storage. It also updates the manifest and progress in the Metadata and Progress Store.

The Upload API returns a chunk acknowledgement or a retryable error to the Backup Agent. The agent can continue after success or retry that chunk later.

The client checks the job with GET /backups/{backupId}/progress. The request passes through the API Gateway and Auth component. It then reaches the Backup API as an authenticated request.

The Backup API reads progress counters from the Metadata and Progress Store. It returns 200 OK with the state, uploaded bytes, completed items, and failed items.

The client reads one consistent progress view. It does not contact individual workers.

The client sends POST /backups/{backupId}/retry through the API Gateway and Auth component. The authenticated request reaches the Backup API.

The Backup API reads failed files or chunks from the Metadata and Progress Store. It requeues that failed work in the Retry Queue. The API returns 202 Accepted with a message that the retry was scheduled.

The Retry Queue dispatches retry work to an Upload Worker. The worker retries the failed upload to Object Storage. It then updates the file state in the Metadata and Progress Store.

This keeps retry processing asynchronous. The client does not wait for every chunk to finish.

The client sends POST /restores through the API Gateway and Auth component. The Restore API receives the authenticated request and creates a restore job for the Restore Worker.

The Restore Worker reads the manifest and file versions from the Metadata and Progress Store. It fetches the required chunks from Object Storage. It then streams the restored files to the Restore Target.

The Restore API returns 202 Accepted or 200 OK. The response contains a restore identifier or the restored files, as shown in the diagram.

The restore data path stays separate from the normal upload path.

The client sends GET /backups/{backupId}/report through the API Gateway and Auth component. The Report API receives the authenticated request and asks the Integrity and Diff Analyzer to generate the report.

The analyzer compares the current snapshot with the previous manifest. It also verifies stored chunk checksums in Object Storage. It records changed, deleted, partial, or corrupted results in the Metadata and Progress Store.

Changed means a file differs from the previous backup. Deleted means the file existed before but is now missing. Partial means the upload or backup is incomplete. Corrupted means checksum validation failed.

The Report API returns 200 OK with the report summary and affected files.

The benefit of this design is that short API calls stay separate from slow file work. POST /backups creates the job quickly, while the queue and workers handle later processing. More Upload Workers can process more chunks without changing the client API. The Metadata and Progress Store keeps job state, manifests, progress, and failed-item records in one place. The downside is extra coordination between APIs, workers, the queue, and storage. HTTPS with JWT or mTLS protects client requests, but identity and certificate handling add operational work. Chunking supports large files and targeted retries, but it also requires manifest and checksum tracking. We accept this complexity because backups are long-running and failures should not restart the whole job.

At a high level, I would own thin official client libraries for common languages. Producer apps use these SDKs to send batches of structured log events to POST /v1/log-events over HTTPS. The SDKs handle authentication, batching, compression, retries with exponential backoff, schema validation, and version compatibility. The ingest API returns 202 Accepted or a 4xx or 5xx error through the client. Custom clients remain useful for unsupported languages or special runtimes. The trade-off is higher SDK maintenance in exchange for faster adoption, stronger compatibility, and lower support cost.

The goal is to make logging-event ingestion simple and consistent across many producer teams. The main challenge is deciding who owns the client-side behavior. I would compare both choices around the same product-owned ingest API.

1. Which clients and core use cases must the API support?
2. What authentication, authorization, and data-validation rules should I assume?
3. What scale, error handling, idempotency, and versioning requirements matter?

I would begin with one stable API owned by the logging-events product team. The endpoint is POST /v1/log-events over HTTPS. It accepts a batch of structured log events.

The product team also owns the API contract and versioning rules. The current contract is versioned as v1. Backward compatibility is part of that contract.

The same team publishes Docs / OpenAPI / Examples. It also owns the Compatibility / Deprecation Policy. These shared assets support both client approaches.

A successful request returns 202 Accepted. A failed request returns a 4xx or 5xx error.

For common languages, I would provide thin official client libraries. Examples include Python, Java, Go, and Node.

The Producer Apps belong to other teams. They call the Official Client Libraries first. The SDK then calls the Logging Events Ingest API.

Before sending the request, the SDK handles authentication using API keys or OAuth. It also handles batching, compression, retries with exponential backoff, schema validation, and version compatibility.

The request path is Producer Apps to Official Client Libraries. It then continues to POST /v1/log-events over HTTPS.

The response follows the reverse path. The API returns 202 Accepted or a 4xx or 5xx error to the SDK. The SDK then returns that result to the Producer App.

Official SDKs give high contract consistency. Supported teams use the same request format and client behavior.

They also make backward compatibility easier to manage. The product team can update supported libraries when the contract evolves.

Adoption is faster because teams do not rebuild common client behavior. They receive authentication, retries, validation, and examples in one supported package.

Centralized fixes are another benefit. The product team can correct shared bugs and security problems in the official libraries.

The main downside is maintenance. The product team must build, test, release, and support several language libraries.

The alternative is to publish documentation and let producer teams build custom clients. These teams use the OpenAPI specification, guides, code examples, and SDK usage samples.

The Producer App calls the Team-built Custom Client. That client sends the same structured event batch to POST /v1/log-events over HTTPS.

The API returns 202 Accepted or a 4xx or 5xx error to the custom client. The custom client then returns the result to the Producer App.

This option gives flexibility for special needs and unusual runtimes. It also lowers the SDK ownership burden for the product team.

However, client behavior can vary. Authentication, batching, compression, retries, schema validation, and version compatibility may be implemented differently.

Official SDKs make support easier because their behavior is predictable. Problems are usually easier to reproduce across producer teams.

Custom clients increase support and debugging work. Each team may use a different implementation and may handle errors differently.

Custom clients can also create compatibility drift. A team may not follow new guidance or deprecation timelines correctly.

The Compatibility / Deprecation Policy reduces this risk. It defines a clear deprecation process, minimum support windows, and change announcements.

Contract tests also help teams check whether their clients follow the shared API contract.

My recommended default is to own thin official client libraries for common languages. I would expose the same stable, versioned ingest API to every client.

I would also maintain OpenAPI documentation, examples, compatibility rules, and contract tests.

Custom clients should be exceptions. They make sense for unsupported languages, special runtimes, or unique requirements.

The producer team should build and maintain its custom client. It should also own support for that implementation.

This approach balances consistency and fast adoption with limited flexibility where it is needed.

The benefit of official SDKs is consistent behavior. Teams receive the same authentication, batching, compression, retry, validation, and compatibility rules. This improves adoption and makes support easier. The downside is maintenance. The product team must release and support several language libraries. Custom clients reduce that SDK work and give teams more flexibility. However, their behavior can vary. One team may retry correctly, while another may not. Compatibility can also drift over time. Clear OpenAPI documentation, deprecation rules, and contract tests reduce this risk. We accept the SDK maintenance cost because most teams gain a faster and more predictable integration path. Custom clients remain exceptions for unsupported languages or special runtimes.