← FIELD applications

FIELD · Customer delivery · 4 min read

A legacy connector with an honest recovery plan

Initial backfill, incremental sync, deletion and reconciliation for one source.

Arunank Sharan · Kuzushi Labs ·

In this article

This worked application uses explicit planning assumptions to demonstrate FIELD. Quantities below are inputs, calculated implications or proposed targets; they are not reported customer results. The engagement decision remains conditional on the evidence described.

Planning basis and engagement boundary

ItemBasis for this application
Demand and context10,000,000 records; 100/page; 10 requests/s quota
First delivery boundaryInitial backfill, incremental sync, deletion and reconciliation for one source
Acceptance to agree and testDemonstrate restart without gaps and catch-up after a six-hour source interruption
Exclusion or constraintA second source or undocumented schema family requires a scope change.

F — Frame the outcome

Deliver a dependable record feed for a downstream business decision, with honestly bounded completeness and freshness rather than a nominal connector launch.

Value measure: Decision-ready record freshness, reconciliation completeness and operator time.

I — Investigate the workflow

Confirm pagination, snapshots, deletion reports and shared quota with the source owner. Determine which missing records change the downstream decision.

First evidence task: Inject omitted updates and a deletion during a repeated backfill page.

E — Engineer the solution

Preserve the quota lower bound, idempotent apply path, watermarks, tombstones and reconciliation; translate outage backlog into a customer catch-up commitment.

The implementation assessment below makes the authority, workload, resource and failure assumptions concrete. Its numbers are calculations from the stated scenario, not a vendor performance guarantee.

Contract

Establish stable record IDs, pagination semantics, snapshot support, source modification timestamps, delete-report cadence and quota sharing. If events omit changes, completeness needs periodic reconciliation; a webhook-only design cannot claim full synchronization.

Implementation plan

A durable coordinator records backfill snapshot/cursor and source version. Bounded fetch workers obey a central rate budget; parser workers validate and stage records; idempotent upserts compare source versions. Preserve malformed data in quarantine. Track watermarks plus periodic source counts/hashes or full scans. Delete reports generate versioned tombstones so old retries cannot recreate removed records.

Sizing

At 100 records/page, 10M records require 100k requests. At 10 requests/s, the ideal request-quota floor is 10,000s≈2h46m40s. At 10KB/record, raw input is 100GB and the ideal full-page rate is 10MB/s. If remote mean latency is 0.5s, five simultaneous requests sustain 10/s in a smooth system; choose a bounded limit using tails and quota behavior, not unlimited threads. Parsing CPU and temporary disk are additional limits.

Outage/catch-up

Suppose 100 updates/s arrive during a six-hour outage: 2.16M updates accumulate. If the effective apply path can process 1,000 records/s while 100/s continue, ideal drain is 2.16M/900=2,400s=40min. This assumes records/page and delta APIs actually allow that rate; one-record update calls would hit a very different quota ceiling.

Schema change

Version parsers and schemas, accept compatible additions, quarantine incompatible records without advancing their disposition silently, and replay after repair. Maintain a validated active view instead of exposing half-parsed data.

Delivery evidence

Replay duplicate/missing/out-of-order events, repeat a page after a crash and process a deletion during backfill. Reconcile source and destination counts by stable IDs, not raw event counts. Expose lag, oldest failed record and completeness limitations to the customer.

L — Launch with evidence

Backfill a representative partition and reconcile stable IDs/versions before publishing. Report missing and quarantined records separately from successful fetches.

Critical decision condition: No completeness claim based only on webhook delivery or aggregate row count.

Attach raw artifacts, the tested configuration, population, denominator, date and limitations to the release record. Missing or stale evidence holds the dependent decision. A favorable value forecast cannot offset a failed critical condition.

D — Develop ownership and reuse

A data operations owner runs replay and schema-change recovery. Publish the completeness limits and escalation route for source omissions.

Candidate reusable asset: Versioned connector contract and deterministic replay suite.

Commercial decision and next commitment

Accountable decision owner: Downstream product owner with source/data operations owner.

The initial commitment is the bounded journey above, with the stated exclusions. Confirm access, customer staffing and acceptance ownership during discovery; price and schedule unresolved dependencies explicitly. A new source, tenant class, language, action or operating envelope requires an impact review rather than silent scope growth.

Approve only the next exposure level supported by the evidence. The next useful investment is: inject omitted updates and a deletion during a repeated backfill page.

Method and references

Apply the FIELD method, economic model and evidence rules. Methodological and technical influences are listed in the source register.