Design parallel investigations with explicit aggregation rules

Pattern 05 companion: Python example · Behavioral tests · Example license

Parallelize questions that can be answered independently

An incident investigator wants a metrics view and a log view of checkout. Each observation can be collected without waiting for the other, so concurrent workers may reduce elapsed time. The useful independence is in the work and its inputs, not simply in assigning different names to otherwise identical agents. If the log query depends on an identifier discovered by the metrics query, the tasks are sequential until that dependency is resolved.

The original fixture supplies two worker callables: metrics returns degraded and logs returns normal. The aggregator reports conflict rather than choosing whichever finishes first. That outcome is deliberate. Different observations can be consistent with a complicated incident, or one can be stale or wrong. Aggregation should preserve the disagreement so an operator can investigate it. The fastest worker is not automatically the most reliable source.

Architecture and request sequence

Component diagram for Design parallel investigations with explicit aggregation rules — Original reference architecture by Sandeep Belgavi. Arrows show the responsibilities and transitions described below.

Request sequence for Design parallel investigations with explicit aggregation rules — Illustrative sequence for this design; failure and recovery variants are explained in the article.

Define the result envelope before fan-out

A production worker result should contain task identity, source identity, observation window, status, evidence references and limitations. Keep execution success separate from the observed service state. A worker can successfully report that the service is degraded; another can fail to retrieve data at all. The teaching program narrows results to normal or degraded and records exceptions as failures. It does not carry real provenance or timestamps, so its output is a concurrency contract demonstration rather than an incident diagnosis.

Give each worker a unique name before submission. The worker registry is a dictionary, so duplicate names cannot be represented as separate entries after construction; caller-side registration should detect accidental replacement before that point. Correlate every submitted task with exactly one accepted completion or failure record. A result without a known task identity should be quarantined rather than counted toward completion.

Make aggregation policy explicit

The fixture returns incomplete if any worker failed. Otherwise, differing accepted values produce conflict and identical values produce consistent. Consistent does not mean correct: two workers can share the same broken source. Conflict does not mean one worker must be discarded. The policy is an original conservative teaching rule that keeps incomplete coverage and disagreement visible. A real application might use a quorum, required worker classes or evidence-weighted analysis, but those choices need their own evaluation.

Do not silently change the denominator when a worker times out. A report based on two of three required observations should state that fact even if the two agree. If optional workers exist, mark them optional at task creation rather than after they fail. Otherwise aggregation can redefine success opportunistically. Preserve individual results alongside the summary so a later reviewer can reconstruct the decision.

Size fan-out against the downstream system

Suppose ten incidents arrive together and each launches four workers. The platform now has forty observation requests, before retries. A per-incident limit of four does not protect a shared telemetry backend from that combined burst. Apply both a per-run fan-out limit and a global dependency limit. Queue work before opening scarce connections. A worker budget should also account for input size and model usage if the observation includes a model assessment.

The example allows one to eight named workers and one to eight execution threads. These are educational bounds, not capacity recommendations. For independent tasks, elapsed time may approach the slowest task plus coordination overhead, but resource consumption remains the sum of their work. Parallelizing an expensive operation does not make it cheaper. Measure end-to-end latency and total usage together before deciding whether the additional concurrency is worthwhile.

Design deadlines without fictional cancellation

The downloadable program waits for all submitted callables and has no timeout. This is safe for its immediate synthetic workers but unsuitable as a general production deadline policy. Python documents that executor shutdown can wait for pending work, and cancelling a future does not stop work already running. Source: Python executor behavior. A timeout on waiting is therefore not the same as a terminated downstream operation.

A production design should give each connector its own transport deadline and use cooperative cancellation or a process boundary when appropriate. After the parent deadline, reject late results from changing the published assessment unless a versioned follow-up explicitly allows them. Preserve whether the underlying work actually stopped. This prevents an apparently completed incident report from concealing continuing resource use or late writes by abandoned workers.

Sources and design limits

The Python reference supports the narrow executor and cancellation facts above. The fan-out rules, incident examples and capacity arithmetic are original designs by Sandeep Belgavi. Read Evals before treating agreement as accuracy. The fixture implementation has no model calls, evidence resolver, durable queue or operational deadline.