Field Service Management: Scale the Data, Not Just the User Count

A field service system needs capacity for work arriving after a disconnection, as well as work arriving now. Amazon's account of queue backlogs explains the underlying problem: when messages arrive faster than a system processes them, waiting time grows and recovery can continue after the original fault has ended. Counting registered technicians does not describe that workload.

We recommend sizing a field application around the data it must accept, reconcile and make available to others. Start with a representative working day, then test the reconnect period. Treat successful storage on a device, server acceptance and completed downstream processing as separate milestones.

Describe the work behind each user

For a capacity review, write down what a technician actually creates and retrieves. Include job updates, inspection answers, photographs and reference records where the application uses them. Record attachment sizes separately from structured records. Do not assume that a test populated with short text fields represents a photograph-heavy workflow.

Describe when those changes arrive. Compare a connected working day with an exercise in which devices retain changes during a disconnection and submit them together afterwards. Use the same job mix in both tests so the comparison isolates the effect of reconnecting.

Measure accepted changes per second, transferred bytes and the time until a submitted change is visible to its intended reader. Also record the oldest waiting item. Amazon recommends measuring message age because producer-side availability and response times do not, by themselves, reveal how far processing has fallen behind.

We would agree an acceptable delay with operations before choosing a database or increasing server capacity. A routine photograph upload and a change to a job's access instructions may need different deadlines. Define those deadlines as requirements to test, rather than assuming every record needs immediate delivery.

Separate acceptance from completion

A queue can separate receipt of work from its processing. Amazon describes durable queues that retain messages until processing succeeds, while warning that a growing backlog can extend recovery time. Adding a queue is therefore a design choice with a delay to manage, not proof that capacity is sufficient.

For a field application, we recommend recording a clear acknowledgement at each stage. Show whether an item is saved locally, accepted centrally or still waiting for another process. Define which acknowledgement permits the device to remove its local copy. Do not label a job fully synchronised merely because an upload request returned successfully.

If work is processed asynchronously, test both admission and completion. Include a case where uploads keep succeeding while a downstream worker is stopped. Check that monitoring exposes the delay and that the user sees the correct state. Then restart the worker and measure recovery while new work continues to arrive.

Make retries safe before increasing them

An interrupted response leaves an important ambiguity. The server may have completed an operation without the client receiving confirmation. Stripe's explanation of idempotent APIs describes this failure and the use of an operation identifier that a client reuses when retrying.

We recommend giving each logical submission a stable identity before its first upload. Retain that identity across retries. Specify how the server recognises an already completed operation and returns its outcome, rather than creating another inspection or completion record. This is an implementation requirement to prove, not a property obtained by adding an identifier field alone.

Test the awkward boundary deliberately: accept a submission on the server, interrupt the response, then submit the same operation again. Check the resulting records and any downstream effects. A successful HTTP response on the second attempt is not a sufficient test of duplicate prevention.

Retry timing matters too. Amazon warns that retries can worsen an overloaded service. Its guidance describes backoff, which increases the wait between attempts, and jitter, which spreads attempts over time. For reconnect tests, include these controls and a defined retry limit. Make exhausted retries visible for investigation rather than silently discarding business records.

Keep duplicate prevention separate from conflicting edits

Retrying one operation is different from two people changing the same record. HTTP provides a mechanism for the latter: RFC 9110's If-Match condition compares an entity tag before applying a request. The standard describes its use to prevent one client accidentally overwriting another's parallel work.

For an editable job record, we recommend agreeing the conflict rule with the people responsible for it. Decide whether a stale update must be rejected, presented for review or reconciled using explicit field rules. Do not treat every difference as an instruction to accept whichever value arrived last.

Include a test in which a device edits an older copy while an office user updates the central record. Verify what each person sees afterwards, which values survive and how an unresolved conflict is surfaced. Keep this correctness test alongside the load test. Faster processing is not acceptance if the wrong update wins.

Test recovery before changing the architecture

Our suggested capacity exercise has a connected baseline, a reconnect burst and a recovery period with continuing traffic. For each stage, record completion delay, failures, duplicate outcomes, conflicts and waiting work. Repeat the exercise after changing one part of the implementation.

Use the results to choose the next investigation. If transfer dominates, review which records and attachments the device requests. If database time dominates, inspect the queries used by that workflow. If workers fall behind, investigate their processing rate and dependencies. Treat caching, additional workers and service separation as candidates to measure, not automatic remedies.

For legacy migrations, run the same representative workflow against the old and proposed paths. Compare the resulting records as well as elapsed time. Keep a recovery procedure for submissions left between systems. We would make a successful reconnect and verified reconciliation part of the migration's acceptance criteria.

Start with one field workflow whose workload you can reproduce. Agree its acceptable delay, prove that retries and parallel edits preserve the intended result, then increase the reconnect load until you find its limit.

Update, October 2026

For a later example of testing capacity across different concurrency levels, see our DGX Spark concurrency benchmark. It concerns model inference, not field synchronisation. Use it as a worked example of varying concurrent work, not as evidence for a field application's throughput.

Sources

• Stripe, "Designing robust and predictable APIs with idempotency", 22 February 2017.
• AWS, "Avoiding insurmountable queue backlogs", 5 December 2019.
• AWS, "Timeouts, retries, and backoff with jitter", 5 December 2019.
• IETF, "RFC 9110: HTTP Semantics", 6 June 2022.