APC Integrated Services Group Software Engineer Interview Guide

The 60-second brief

Candidates describe APC Integrated Services Group openings under the Software Engineer title that span two examples: a Junior SQL Developer position focused on database architecture, and an Email Marketing Systems Engineer position that manages communication infrastructure. No product line, customer list or team structure is reported, so the two titles are the concrete clues. Both point at relational data and at messaging systems that have to keep running. Skills candidates list as nice to have are email marketing automation tools, high-volume data environments and cloud-based infrastructure.

This guide is for candidates applying to APC Integrated Services Group as a Software Engineer, from a Junior SQL Developer profile to a systems-oriented profile. It covers the five reported questions (SQL query optimization, debugging a failing stored procedure, join types, data integrity in large migrations and indexing), the reported topic areas of SQL, database development and backend application development, and the behavioral stories you will need to attach to them.

No round sequence, round count or format has been reported for this loop. What candidates report is a set of five questions about SQL and database work, which this guide treats as one preparation block until your recruiter confirms the stages.

Focus areas

• Software Engineering
• Email Marketing Systems
• SQL

Overview

Candidates report five questions, and every one of them sits in the database area: tuning complex SQL, debugging a stored procedure that fails in production, choosing between join types, protecting data during large migrations and designing indexes for read and write speed. Reported topic areas around them are Software Engineering, Email Marketing Systems, SQL, Database Development and Backend Application Development. The requirements candidates describe name SQL proficiency, experience with database management or systems engineering, and a working grasp of the software development lifecycle.

Two of the five questions ask about your experience, so they call for a story with numbers rather than a definition. The other three have a checkable technical core: a debugging sequence for a stored procedure, the semantics of inner, outer, cross and anti joins, and a migration plan with verification at each step. Prepare each of the five in two layers. First give the technical answer in a few sentences, then attach a real project where you applied it.

The Email Marketing Systems Engineer example and the nice-to-have list (email marketing automation tools, high-volume data, cloud infrastructure) suggest reading around messaging pipelines too. Nothing reported says what those questions look like, so prepare the general reliability ideas: retries that cannot double-send, queues that absorb bursts, logging that lets you reconstruct what happened to one message.

Be exact about your depth. If you have used a tool once, say so and describe what you did with it; a follow-up on a technology you list on your resume is easier to survive when your claims were modest and specific from the start.

Where to focus your preparation

Only one stage is listed because no round names have been reported for this loop; confirm the real sequence and whether you will write code with your recruiter.

Preparation focus

Candidates report no round names, order or durations for APC Integrated Services Group, only a set of questions on SQL and database work, plus topic areas that include backend application development and email marketing systems. Treat this stage as the whole preparation block: work the five reported questions as spoken answers backed by real examples, and confirm with your recruiter whether any stage involves writing SQL or code live.

What to demonstrate

• Command of SQL: query optimization, join semantics and indexing
• A method for diagnosing a failing stored procedure in production
• How you protect data integrity when moving large volumes between systems
• Whether you can tie your technical choices to projects on your resume

How to prepare

• Write a one-minute answer each for join types, indexing and migration integrity, then one real project that illustrates each
• Practice reading execution plans for a slow query and explaining the single change that fixed it, with before and after numbers
• Write out your debugging sequence for a failing stored procedure, from the first log you read to how you confirm the fix
• Ask the recruiter whether SQL will be written live, which database engine the team uses and whether a design discussion is part of the loop

Where candidates lose points

Defining joins from a textbook without showing what happens to unmatched rows

For each join type state which rows survive, then give one query where a LEFT JOIN with a filter in the WHERE clause silently becomes an inner join. Also cover anti-joins (NOT EXISTS) and the NULL behaviour of NOT IN.

Answering the indexing question with 'add an index on the slow column'

Talk about composite order, covering indexes, selectivity and the write cost of each extra index. Close with how you measured both read and write latency before and after.

Debugging a failing stored procedure by guessing at the code

State a sequence: capture the exact error and parameters, check what changed (deploy, schema, data volume), reproduce in a non-production copy, add logging or step through, then fix and add a regression check. Mention locks, permissions and unexpected NULLs as likely causes.

Describing a migration as 'copy the data and verify it looks right'

Name concrete controls: a backup and rollback path, a dry run on a copy, row counts and checksums per table, referential and constraint checks, batched loads inside transactions, and a reconciliation query before cutover.

Claiming tools such as email automation platforms or cloud services you have barely touched

State your real depth in one sentence and describe the exact task you completed with it. Be ready to explain why you chose that tool over the alternatives.

Questions & practice

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Explain the difference between various join types and when you would use each.

Medium · Technical Proficiency and Database Manag

Approach

1. Define each join by which rows survive: INNER keeps only matching pairs; LEFT keeps every left row with NULLs for unmatched right columns; RIGHT is a LEFT with the tables swapped; FULL OUTER keeps unmatched rows from both sides; CROSS returns every combination (m x n rows); a self join compares rows within one table, such as employee to manager.
2. Tie each to a use: INNER when both sides must exist (orders with their customer), LEFT to keep the driving set (all customers, including those with no orders), FULL OUTER to reconcile two sources such as an old and a new table after a migration, CROSS to build a date-by-entity grid before filling gaps.
3. Name the traps: a WHERE condition on the right table's columns discards the NULL rows and turns a LEFT JOIN into an inner join, so put that condition in the ON clause; NULL keys never match in an equality join; NOT IN against a subquery that returns a NULL yields no rows, so use NOT EXISTS or LEFT JOIN ... WHERE right.key IS NULL for anti-joins.
4. Check cardinality before aggregating: joining a one-to-many child duplicates parent rows and inflates SUMs, so aggregate the child in a subquery or CTE first, or use EXISTS when you only need to know a match exists.
5. Know the physical side: nested loops suits a small outer input with an index on the inner join key, hash join suits large unsorted inputs but only for equality joins, and merge join needs both inputs sorted on the key.

Follow-up

• Write a query for customers who have never placed an order in two ways. Which would you choose, and why?
• Your LEFT JOIN suddenly returns fewer rows than the left table has. What would you look for?
• When would the optimizer choose a hash join over nested loops, and what index would change that choice?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

What strategies do you use to ensure data integrity during large-scale migrations?

Medium · Technical Proficiency and Database Manag

Approach

1. Profile the source before moving anything: row counts, NULLs in columns that will become NOT NULL, duplicates on the intended keys, orphaned foreign keys, encoding and out-of-range values. Enforce primary key, foreign key, NOT NULL and CHECK constraints on the target so bad rows fail loudly, and route rejects to an error table with the reason.
2. Take a backup and test the restore before starting. Move data in batches keyed by primary-key range, each batch in its own transaction and idempotent (MERGE or insert-where-not-exists) with a recorded checkpoint, so a rerun after a crash resumes without duplicates.
3. Validate with more than row counts: compare per-range aggregates (sums of amounts, distinct key counts, a hash of the row's columns per key) and run a FULL OUTER JOIN or EXCEPT on keys to list missing or changed rows, then spot-check samples end to end.
4. For a table that keeps taking writes, capture changes during the copy (change data capture or dual writes), backfill, apply the catch-up, then cut over with a short write freeze. Use expand-then-contract schema changes so old and new code both work, and keep the old table until validation passes so rollback is possible.
5. State the trade-offs: larger batches finish sooner but hold locks longer and grow the transaction log; dropping indexes or disabling constraints speeds loading, but they must be rebuilt and revalidated afterwards (in SQL Server, re-enable WITH CHECK so the constraint is trusted again).

Follow-up

• Row counts match, but a downstream report shows different totals. How do you find the rows responsible?
• The batch job dies partway through. What in your design makes rerunning it safe?
• How would you migrate a large, write-heavy table without a long outage?

Publish rate-limit and deadline semantics the edge actually enforces

Easy · rate limiting · backpressure · retries

The edge API serves about 3k requests/second steady and 9k at peak against a 400 ms p99 budget, with an explicit bounded concurrency limit per instance. Limits exist per principal and per tenant. Callers are a partner integration running nightly bulk loads and a browser app. Specify the counting algorithm and window, which limit a request is charged against, the headers a well-behaved client reads, the status and body when a limit is hit, how that differs from the response when an instance is shedding load, and what each caller does with each.

Approach

1. Choose the counter and name its failure mode. Fixed windows admit nearly twice the limit across a boundary - a full burst at the end of one window and another at the start of the next. A token bucket states sustained rate and burst separately, which is exactly what a nightly bulk load needs. A sliding-window counter is more faithful and costs more state per key. State the choice and the burst it permits.
2. Charge each request against both keys and reject on the stricter. The tenant limit protects the shared primary, which absorbs roughly 1.2k writes/second in total; the per-principal limit stops one credential inside a tenant from consuming that tenant's whole allowance. The tenant is the fairness unit for the same reason it is the leading column of every index.
3. Advertise limit, remaining and reset for the binding key on every response, not only on rejections, so a client can pace before it is refused. Pick one naming scheme - the RateLimit-* draft fields or an X-prefixed set - document the units, and never change them afterwards.
4. Separate two rejections that look identical to a naive client. 429 means this caller exceeded its own share and Retry-After is a real schedule it should obey. 503 means the instance is at its concurrency bound and shedding, which is a statement about the server; a fleet-wide 503 retried on a fixed delay resynchronises every client into one stampede, so full jitter is mandatory there and the delay is the client's guess, not ours.

Follow-up

• One tenant stays under its limit and still degrades everyone else during a backfill. What changes - the limiter, the worker concurrency caps, or both?
• How are counters kept correct across 20 to 40 stateless instances, and what does your answer cost per request?

How do you approach debugging a stored procedure that is failing in a production environment?

Medium · Technical Proficiency and Database Manag

Approach

1. Capture the exact failure before theorising: error number and message, the failing statement and line, the parameter values and the time. In SQL Server, a TRY/CATCH block that logs ERROR_NUMBER(), ERROR_LINE() and ERROR_PROCEDURE() to an error table gives you this; in PostgreSQL, GET STACKED DIAGNOSTICS inside an EXCEPTION block does the same.
2. Establish what changed and whether it fails on every call or only on some inputs: a new version of the procedure, a schema change on a table it reads, new data values (NULLs, duplicates, values that overflow a column type), or a plan change after a statistics update.
3. Reproduce outside production with the failing parameters against a restored copy or staging data of similar volume, inside a transaction you roll back. Never edit the live procedure to add debug output.
4. Classify the failure, because each class has a different fix: data errors (constraint violation, conversion error, divide by zero), concurrency (deadlocks, which SQL Server reports as error 1205, lock timeouts, blocking chains), or performance timeouts, often parameter sniffing, where the plan cached for one atypical value is reused for all; compare actual execution plans or Query Store history.
5. Check for partial writes: if the procedure failed mid-transaction, confirm what was committed (SET XACT_ABORT ON in SQL Server rolls back the whole transaction on most runtime errors). Ship the fix through version control with a test for the failing input, and keep the error logging in place.

Follow-up

• It runs fine when you execute it in SSMS but times out from the application. What could explain that?
• The procedure updated two of three tables before it failed. How do you find and repair the inconsistent rows?
• How would you confirm the failures are deadlocks, and what would you change in the procedure to reduce them?

Suggested practice checklist

Seven days built around the five reported questions: joins, query tuning, indexing, stored procedure debugging and migrations, then messaging reliability and behavioral rehearsal. Practice-library questions are attached where they exercise the same skills.

Day 1 — Confirm the format and master join semantics

• Email your recruiter to ask for the sequence of stages, whether SQL or code is written live and which database engine the team works with.
• Create two small tables with unmatched rows on both sides and run inner, left, right, full, cross and anti-join (NOT EXISTS) queries. Write one sentence on which rows each keeps.
• Build a one-to-many join and show how a SUM inflates, then fix it by aggregating before the join.

Deliverable: A recruiter message sent, a join cheat sheet with one query per join type, and one corrected inflated-sum query.

Day 2 — Query tuning with execution plans

• Take a slow query on a table with a few hundred thousand rows and read its execution plan. Identify the costly operator and make one change at a time.
• Rewrite a correlated subquery as a join and as a window function, and confirm the rows match with an EXCEPT comparison.
• Convert an OFFSET paging query to keyset paging, then write the story of your best real tuning win with before and after numbers.

Deliverable: A before and after plan comparison for one query, a keyset paging rewrite, and a written tuning story with numbers.

Day 3 — Indexing for reads and writes

• On the same table, test composite indexes in different column orders and a covering index. Record query time for each.
• Measure insert throughput with zero, two and five indexes on the table, and note the cost per index.
• Write a query against index usage statistics that lists indexes never read, and write your answer to the indexing question around it.

Deliverable: A table of read time and write cost per index design, plus a spoken-answer outline for the indexing question.

Day 4 — Debugging a failing stored procedure

• Write a stored procedure with three planted faults: a NULL that breaks a calculation, a changed column type and a lock wait. Then diagnose each from logs and error text alone.
• Write your debugging sequence as numbered steps, from capturing the error and parameters to the regression check after the fix.
• Add structured logging with a correlation id inside the procedure and show how it shortens diagnosis.

Deliverable: A numbered debugging runbook and a procedure instrumented with logging, with each planted fault diagnosed in writing.

Day 5 — Data integrity in large migrations

• Plan a migration of a large table to a new schema: backup, dry run on a copy, batch size, rollback path and cutover.
• Write reconciliation queries comparing source and target: row counts, per-column checksums and orphan-key checks.
• Do the diff exercise comparing a projection against the primary without per-row lookups, then explain how its set-based approach helps a migration check.

Deliverable: A migration plan with rollback and a set of working reconciliation queries.

Day 6 — Backend reliability for high-volume messaging

• Sketch a queue-based send pipeline for bulk email: batching, retries, idempotency keys so a retry cannot double-send, and a log that traces one message end to end.
• Work the rate-limit and deadline design exercise and compare its ideas with your pipeline sketch.
• Do the concurrency exercise on overlapping job attempts, to practise interval reasoning over records with start and end times.

Deliverable: A one-page pipeline diagram with failure handling, plus solutions to the two practice exercises.

Day 7 — Behavioral rehearsal and full dry run

• Say aloud your SQL tuning story and your indexing story in STAR form, each with a measured result and a trade-off.
• Rehearse the exercise about telling callers their integration will break, which trains you to describe a change that affects people outside your team.
• Run all five reported questions back to back as spoken answers, then write two questions to ask the team.

Deliverable: Recorded or written spoken answers to all five reported questions, and two questions for the team.

Stories from your database work

The two reported questions about SQL experience and indexing strategy ask for your own history, so they need a real project with measured results. Prepare stories from your database and backend work where you made the call, and keep a technical answer ready behind each one.

1. Tell me about a production failure in a stored procedure, scheduled job or backend service that you diagnosed. What did you check first, and how did you confirm the fix?
2. Describe a data migration you ran or helped run. What did you do to confirm nothing was lost or changed?
3. Tell me about a code review or disagreement over a schema or query design, and how you settled it with evidence.
4. Describe a time you worked with a product manager or another team to turn an unclear request into a defined piece of work.

Describe your experience with writing complex SQL queries and optimizing them for performance.

Medium · Technical Proficiency and Database Manag

Approach

1. Pick one query you owned end to end and open with its cost: what it returned, how large the tables were and how long it ran before you touched it. Use numbers you can defend, such as rows scanned, runtime or I/O.
2. Walk the diagnosis in order. Read the execution plan and find the operator doing the damage: a full scan, a nested loop over a large outer input, a sort spilling to disk or a row estimate far from reality. Then name the one change that fixed it, for example an index, a correlated subquery rewritten as a join or window function, a function removed from an indexed column, or statistics refreshed.
3. Show verification: same data and parameters, plans before and after, and proof the result set was identical (row counts, a checksum or an EXCEPT comparison). Say whether the gain held at production size, not just on a test copy.
4. Name the trade-off you accepted, such as an extra index slowing writes or a pre-aggregated table going stale, and how you contained it.
5. The mistake that sinks this answer is a list of SQL features. Keep it to one story where you made the decision and can show before and after.

Follow-up

• How did you know the new plan would hold when the data distribution or parameter values changed?
• What would you have tried first if you were not allowed to add an index?
• How did you prove the rewritten query returned exactly the same rows as the original?

How do you handle indexing strategies to improve database read/write speeds?

Medium · Technical Proficiency and Database Manag

Approach

1. Start from the workload, not the schema. Say you look at the read-to-write ratio and the most expensive queries from query statistics, and index for measured queries rather than columns that look important.
2. Cover read-side technique: composite index column order (equality columns first, then range, then sort columns), covering indexes that carry the selected columns so no table lookup is needed, partial indexes for a small hot subset, and avoiding functions or implicit casts on indexed columns that make an index unusable.
3. Cover write-side cost: every index adds work to each insert, update and delete, adds storage and can cause page splits. Describe how you find unused or duplicate indexes with usage statistics before dropping them, and how you load large batches, for example by loading first and building indexes after.
4. Anchor it in one table you changed: the baseline read and write latency, the index change, the measured result on both sides, how you rolled it out without blocking traffic, and what you would adjust next time.
5. Mention upkeep: statistics, index bloat or fragmentation, and a periodic review so the index set matches the current queries.

Follow-up

• How do you decide the column order in a composite index?
• How would you find indexes that slow writes but never serve a read?
• What changes about your indexing choices on a table that takes heavy inserts, such as a high-volume event log?

Tell callers you do not own that their integration breaks

Medium · deprecation · compatibility · stakeholders

A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

Approach

1. Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
2. Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
3. Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
4. Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.

Follow-up

• How would you detect a consumer that reads the field only during a monthly export?
• One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?