Request Response Capability Provisioning

Make a scarce or specialized capability addressable as a service that many independent clients can request and receive responses from under explicit capacity and failure rules.

Essence

Make a scarce or specialized capability addressable as a service that many independent clients can request and receive responses from under explicit capacity and failure rules.

A capability becomes reusable when a client does not need to own, understand, or negotiate its internal operation in order to ask for a result. The provider concentrates expertise, authority, state, equipment, or computation behind a stable surface; clients initiate only when they need it. This reduces duplicated capability and bilateral coordination, but it also creates a shared dependency. The architecture succeeds only when request and response semantics, addressability, finite capacity, isolation, and failure behavior are designed together rather than treating the server as an infinite black box.

Canonical structure: For clients C = {c_i} and provider S holding capability K: c_i –request(r_i, context_i)–> S[K]; S admits and schedules r_i under capacity μ and policy P, then S –response(result_i | error_i | deferred_i)–> c_i. The defining relation preserves client initiation, provider addressability, many-client multiplexing, and capability asymmetry; stable operation additionally requires effective offered load λ to remain within a governed service envelope rather than growing without bound.

Compression statement

When many actors repeatedly need a capability they do not hold, create a bounded provider role, publish a stable address and interface, let clients initiate standardized requests, multiplex those requests over finite provider capacity, return explicit results or errors, isolate clients from one another, and govern overload, access, availability, and accountability as first-class properties of the relation.

Canonical formula: For clients C = {c_i} and provider S holding capability K: c_i –request(r_i, context_i)–> S[K]; S admits and schedules r_i under capacity μ and policy P, then S –response(result_i | error_i | deferred_i)–> c_i. The defining relation preserves client initiation, provider addressability, many-client multiplexing, and capability asymmetry; stable operation additionally requires effective offered load λ to remain within a governed service envelope rather than growing without bound.

When this pattern is needed

Use this pattern when many independent actors repeatedly need a capability they do not own and a bounded provider can expose that capability through a stable service surface. The provider may hold computation, authoritative data, scarce equipment, professional judgment, institutional authority, inventory, or a maintained process. The pattern is strongest when clients should not need to understand or reproduce the provider’s internals, yet must receive predictable results, refusals, or errors.

The four diagnostic commitments must travel together:

• Client initiation: ordinary work begins because a client asks or explicitly opts into later delivery.
• Provider addressability: clients can locate a stable service identity without a bespoke personal relationship.
• Many-client multiplexing: one logical provider serves independent clients that need not know one another.
• Capability asymmetry: the provider holds or operates something the clients lack and are trying to consume.

Structural problem

Many independent actors need repeated access to the same scarce, authoritative, stateful, expensive, or specialized capability, but each actor currently duplicates it, negotiates ad hoc access, depends on undocumented individuals, or couples directly to internal implementation. Attempts to centralize the capability without a request–response contract then create an opaque shared choke point whose capacity, failures, and access rules are discovered only during overload.

The root tension is: Concentrating capability behind one address can create reuse, consistency, specialization, and simpler clients, but it also concentrates dependency, power, demand, failure, and information. The same asymmetry that makes the service useful can turn the provider into a bottleneck, surveillance point, gatekeeper, or single point of failure.

Intervention logic

1. Define the capability being provided and why it should be held or operated by a bounded provider rather than duplicated across clients.
2. Identify the client population, request classes, legitimate exclusions, protected groups, and likely demand correlations.
3. Name the capability owner and its authority, maintenance, quality, security, and accountability obligations.
4. Create a stable address, directory entry, role, portal, or endpoint by which clients can locate the service.
5. Specify the interface contract: operations, inputs, preconditions, outputs, errors, compatibility, and versioning.
6. Specify initiation semantics so the client knows when a request has been accepted, rejected, staged, or completed.
7. Separate successful response, partial response, refusal, timeout, cancellation, and unknown outcome so recovery behavior is safe.
8. Model sustainable service capacity, service-time variability, downstream constraints, bursts, and synchronized demand.
9. Choose multiplexing, concurrency, queueing, priority, fairness, and admission rules appropriate to the consequences of delay or denial.
10. Add access control, identity, quota, privacy, and isolation proportional to the capability and client risk.
11. Instrument demand, backlog, latency, errors, saturation, abandonment, differential service, and provider health.
12. Define overload behavior before overload occurs: stage, throttle, shed, degrade, redirect, reserve, or add capacity.
13. Define failure and recovery: fallback, replica, retry budget, deduplication, failover, incident communication, and reconciliation.
14. Evolve provider internals behind the contract, version the observable surface deliberately, and retire interfaces only with migration support.
15. Periodically reassess whether central capability ownership remains justified or whether federation, local autonomy, replication, or client-side capability should replace part of the service.

The intervention is not complete when an endpoint or office exists. The relation becomes durable only when clients can discover it, requests and responses are unambiguous, shared capacity is bounded, clients are isolated, overload and failure are safe, and the provider remains accountable for the capability it claims to supply.

Key components

Component	Description
Capability Owner ↗	Holds, operates, or has legitimate authority over the capability that clients cannot or should not each reproduce independently. Reuse the indexed component. The owner may be a software service, specialist team, laboratory, office, institution, machine, or other bounded provider. Ownership must include accountability for capacity, quality, access, and failure.
Client Population ↗	Defines the independent actors or processes that initiate requests, consume responses, and may contend for the same provider capacity. Clients need not know one another. Their independence is what creates multiplexing benefits and correlated-demand risks.
Addressable Service Endpoint ↗	Provides a stable destination that clients can locate and invoke without negotiating a bespoke relationship with the capability owner each time. Addressability may be a network address, directory entry, counter, portal, phone number, named role, institutional office, or routing identity. A mere internal capability with no discoverable access surface is not enough.
Interface Contract ↗	Specifies the externally observable operations, admissible inputs, response forms, preconditions, and compatibility promises at the service boundary. Reuse the indexed component. The contract suppresses internal implementation detail while making client expectations testable. It should not promise stronger availability, consistency, or latency than the provider can support.
Request Contract ↗	Defines how a client initiates work, identifies the desired operation, supplies required context, and signals urgency, identity, or completion expectations. The contract should distinguish valid demand from malformed, duplicate, unauthorized, or impossible requests and state whether requests may be retried safely.
Request Context and Identity ↗	Carries the client identity, authority, correlation, provenance, locale, purpose, and other bounded context needed to interpret and govern a request correctly. Context should be minimized to what service delivery, safety, accounting, and lawful audit actually require. Hidden or excessive context creates privacy, discrimination, and coupling risk.
Response and Error Contract ↗	Defines successful results, partial results, refusals, errors, timeouts, retry guidance, and completion signals so clients can react without guessing. A response contract is load-bearing even when service is asynchronous. Silence, ambiguous failure, or hidden partial completion creates unsafe retries and tight coupling.
Multiplexing and Scheduling Policy ↗	Determines how one capability provider serves many independent clients over time or concurrently, including ordering, batching, preemption, and concurrency limits. The policy converts a one-to-many relation into governable service rather than accidental contention. It should make explicit whether service is first-come, priority-based, fair-share, deadline-aware, or class-partitioned.
Finite-Capacity and Admission Boundary ↗	States the provider capacity envelope and the rule for accepting, staging, throttling, rejecting, or shedding demand when arrivals exceed safe service capacity. Client–server structure creates a shared choke point. Capacity must include human attention, compute, authority, inventory, bandwidth, expertise, and downstream dependencies—not only nominal request throughput.
Access Policy ↗	Controls which clients may invoke which capability under what identity, purpose, quota, credential, payment, or safety conditions. Reuse the indexed component. The policy should be no broader than necessary and must include accessible, auditable exception and appeal paths where service access affects rights or essential needs.
Isolation Boundary ↗	Prevents one client, request, tenant, or failure from corrupting another client’s work, data, quota, or service quality. Reuse the indexed component. Isolation may be logical, temporal, spatial, procedural, financial, or organizational. Without it, multiplexing turns independent clients into hidden mutual dependencies.
Observability, Quota, and Accounting ↗	Measures demand, service time, backlog, errors, usage, cost, client class, saturation, and dependency health while enforcing transparent quotas or budgets where needed. Reuse the indexed component. Observation must support diagnosis and fairness without collecting unnecessary client data or enabling abusive surveillance.
Availability and Failure Contract ↗	Defines what happens when the provider, network path, dependency, or response deadline fails, including degradation, failover, retry, fallback, and recovery semantics. The contract should prevent clients from converting provider failure into retry storms, duplicate effects, indefinite blocking, or silent data loss.
Registry ↗	Maps a stable service name or role to a current endpoint, provider, schedule, location, or eligibility route. Reuse the indexed component when provider identity or location changes, multiple instances exist, or clients cannot rely on a fixed address.
Session-State Boundary ↗	Defines whether and where client-specific state persists across requests and how it is created, updated, expired, migrated, or recovered. Use only when the service genuinely requires continuity. Hidden session state reduces substitutability, complicates scaling, and increases privacy and failure risk.
Asynchronous Completion Channel ↗	Lets the provider acknowledge a request and deliver completion, progress, or failure later without holding the client in a synchronous wait. Useful for long-running or bursty work, but it adds correlation identifiers, durable state, notification reliability, and cancellation obligations.
Cache or Replica Layer ↗	Serves repeated or read-heavy requests from replicated or precomputed state to reduce latency and protect the authoritative provider. Use only with explicit freshness, invalidation, consistency, and privacy rules. A cache changes response semantics and cannot be treated as invisible.
Priority Service-Class Policy ↗	Partitions or weights service for critical, latency-sensitive, routine, bulk, or protected client classes. Useful when equal ordering would be unsafe or unfair. The classes and evidence for differential treatment must remain inspectable and revisable.
Fallback Direct Channel ↗	Preserves a limited alternate route when the shared service is unavailable or an exceptional case cannot be represented by the standard contract. Reuse the indexed component cautiously. A fallback that becomes the normal path can bypass controls, create inequity, and conceal chronic service failure.
Service-Level Boundary ↗	Defines measurable commitments for timeliness, availability, quality, completion, error recovery, and support by request class. Reuse the indexed component. Service levels are constraints on the relationship, not proof that the architecture is appropriate.
Arrival Rate Estimate ↗	Estimates average, peak, seasonal, and correlated request arrivals by client class and time window. Reuse the indexed component when capacity planning matters. Average arrivals alone are inadequate for synchronized release, retry storms, or rare joint peaks.
Service Rate Capacity Model ↗	Estimates sustainable service throughput, latency, concurrency, and degradation across provider and dependency states. Reuse the indexed component. The model should include variability, setup cost, tail latency, error recovery, and downstream constraints.
Backlog Visibility Signal ↗	Shows accepted but unfinished demand by age, class, ownership, blockage, and expected drain so clients and providers can distinguish delay from loss. Reuse the indexed component for asynchronous or capacity-constrained services. A backlog signal should include abandoned, rejected, and aging work rather than only the visible queue length.
Request Fingerprint ↗	Carries a stable identity for duplicate detection, safe retry, deduplication, and response reconciliation. Reuse the indexed component where clients may retry after ambiguous failure or where operations have non-repeatable effects.

Common mechanisms

API or RPC Endpoint

Exposes a machine-callable request surface with typed operations, inputs, outputs, errors, identity, and compatibility rules. This is a interface mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Shared Service Desk

Provides a human-operated, addressable capability that accepts requests from many users, triages them, and returns resolutions or escalations. This is a institution mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Intake Portal

Collects structured requests, validates required context, communicates status, and routes work into the provider’s service process. This is a software_or_tool mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Ticketing System

Creates durable request records with identity, priority, ownership, status, history, and response closure. This is a software_or_tool mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Central Registry

Publishes the current address, eligibility, interface version, or provider instance behind a stable service identity. This is a artifact mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Service-Level Agreement

Makes service commitments, exclusions, measurement rules, escalation paths, and responsibilities explicit between provider and clients. This is a document mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Autoscaling Worker Pool

Adds or removes parallel service workers in response to observed demand while respecting stability and cost guardrails. This is a software_or_tool mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Parallel Server Activation

Brings additional provider instances or teams online when one instance cannot safely serve the active request load. This is a procedure mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Rate Limit with Burst Allowance

Constrains sustained request rate while permitting bounded short bursts so a client cannot monopolize finite shared capacity. This is a protocol mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Weighted Fair Queue

Schedules request classes by explicit service shares so high-volume clients do not starve smaller or protected clients. This is a protocol mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Idempotent API

Makes retrying a request with the same identity safe by preventing duplicate externally visible effects. This is a interface mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Safe Retry Protocol

Coordinates timeout, backoff, deduplication, maximum attempts, and terminal failure so recovery does not become a retry storm. This is a protocol mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Service-Level Monitor

Tracks latency, completion, availability, backlog, errors, saturation, and service differences across client classes. This is a metric_or_dashboard mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Authentication Broker

Verifies client identity and supplies bounded credentials or claims at the service boundary. This is a software_or_tool mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Cache or Read Replica

Serves eligible repeated reads from copied state to reduce latency and protect the authoritative capability provider. This is a software_or_tool mechanism; it operationalizes part of the archetype and should not be mistaken for the parent pattern.

Mechanism choice follows service duration, consequence, and substrate. A low-latency machine service may emphasize typed interfaces, idempotency, quotas, replicas, and automated health. A human service may emphasize structured intake, case ownership, fair queues, accessible channels, professional discretion, and explanation. Long-running work needs durable asynchronous completion. Safety-critical work needs stronger identity, audit, reconciliation, and continuity.

Parameter dimensions

• Client population: number, heterogeneity, geography, trust level, access needs, and independence.
• Capability concentration: how scarce, authoritative, expensive, stateful, or safety-sensitive the provider capability is.
• Initiation pattern: synchronous call, asynchronous submission, appointment, ticket, specimen, job, or opt-in callback.
• Arrival process: average rate, peak rate, seasonality, burst size, tail correlation, retry behavior, and synchronized release.
• Service process: service-time distribution, concurrency, batching, setup cost, downstream dependencies, and human discretion.
• Statefulness: stateless request, short session, durable case, authoritative shared state, or externally stored context.
• Response semantics: immediate result, acknowledgment, partial result, deferred completion, refusal, cancellation, or unknown outcome.
• Capacity policy: queue, reservation, throttle, shed, scale, replicate, degrade, redirect, or prioritize.
• Fairness policy: first-come, protected share, urgency, deadline, risk, entitlement, quota, or weighted fair service.
• Consistency and freshness: authoritative response, cached response, replica lag, version, and conflict handling.
• Failure envelope: timeout, retry budget, deduplication, failover, fallback, recovery point, and client reconciliation.
• Governance: capability authority, access legitimacy, privacy, audit, appeal, service commitment, and exit alternatives.

Invariants to preserve

• Clients initiate ordinary service interactions or explicitly opt into later callbacks; the provider does not silently convert the relation into unsolicited control.
• The provider remains discoverable through a stable identity even when implementation or instance changes.
• The externally observable request and response contract remains testable and versioned.
• The provider is accountable for the capability it claims to hold, including quality, authority, maintenance, and safe failure.
• Independent clients remain isolated from one another’s data, state, quota, and failure except where sharing is explicit and legitimate.
• Admission and scheduling do not imply infinite capacity; overload produces bounded, communicated behavior.
• Every accepted request reaches an explicit terminal state or a recoverable reconciliation state.
• Retries cannot create duplicate harmful effects or unbounded correlated demand.
• Access and differential service rules are explicit, legitimate, and auditable.
• Critical clients retain an acceptable recovery, fallback, or continuity path when the provider fails.

Target outcomes

• Specialized capability is reused without requiring every client to own or understand its implementation.
• Clients interact through a predictable, discoverable, and evolvable service surface.
• Quality, authority, security, and maintenance responsibility become concentrated and inspectable.
• Demand and finite capacity become measurable rather than hidden in informal relationships.
• Independent clients can share the provider without accidental interference or arbitrary priority.
• Overload, failure, timeout, and retry behavior remain bounded and understandable.
• Provider implementation can change or replicate without coordinated rewrites across all clients.
• Backlog, service differences, and denied demand become visible enough for capacity and fairness decisions.
• The architecture can scale through controlled replication, caching, queuing, or service-class design rather than ad hoc workarounds.
• The organization can decide deliberately when to keep capability centralized and when to distribute or federate it.

Applicability and weak conditions

The pattern works best when the capability is genuinely reusable, can be represented behind an observable contract, and benefits from coherent ownership. It is weak when the capability is irreducibly local or tacit, when peers are symmetric, when centralization creates unacceptable power or fragility, or when the provider cannot make meaningful commitments about access, response, capacity, and failure.

Variants

Stateless Request–Response Service

Processes each request from the supplied context without depending on hidden client-specific state retained from earlier requests.

Its distinctive feature is: Each request is self-contained at the service boundary.

Sessionful Capability Service

Maintains client-specific state across a sequence of requests so later responses depend on an established interaction context.

Its distinctive feature is: The provider owns durable session state and must preserve continuity across requests.

Asynchronous Queued Service

Acknowledges a request, stages it durably, and returns completion or failure later through a correlated channel.

Its distinctive feature is: Request acceptance and result delivery are separated in time by a durable work state.

Human Expert Capability Service

Exposes scarce judgment, authority, craft, or expertise through a repeatable intake-and-response service for many requesters.

Its distinctive feature is: Service capacity is bounded by human attention, competence, discretion, and fatigue.

Replicated Capability Service

Implements one logical provider through multiple service instances or sites so demand and failure can be distributed while the client sees a stable capability surface.

Its distinctive feature is: One logical server role is realized by multiple coordinated instances behind a stable address or contract.

The variants remain under one parent while client initiation, provider addressability, many-client multiplexing, and provider-held capability remain intact. Forms that reverse initiation, distribute capability symmetrically, or make mediation rather than provision the core function should be separated.

Tradeoffs

• Capability reuse and consistency versus concentration of dependency and authority.
• Simpler clients versus a more complex, powerful, and operationally critical provider.
• Central observability versus client privacy and provider surveillance risk.
• Shared utilization efficiency versus noisy-neighbor interference and correlated overload.
• Stable interface contracts versus slower evolution or lowest-common-denominator service design.
• Synchronous simplicity versus temporal coupling and blocked clients.
• Asynchronous resilience versus more durable state, reconciliation, and cancellation complexity.
• Stateless substitutability versus larger requests or repeated context transfer.
• Session continuity versus affinity, privacy, migration, and recovery burden.
• Central quality control versus reduced local autonomy and contextual adaptation.
• Replication and availability versus consistency, coordination, and cost.
• Strict admission protection versus unmet demand, inequitable exclusion, and hidden shadow channels.

Failure modes

Infinite-server assumption

Cause: Clients and planners treat provider capacity as unbounded or use average throughput while ignoring variability and dependencies.

Mitigation: Model arrival distributions and service capacity, publish a safe envelope, instrument saturation, and define admission and overload behavior.

Single point of failure

Cause: One provider, address, authority, state store, or downstream dependency is required for all clients.

Mitigation: Use fault analysis, replication or fallback where justified, degraded modes, tested recovery, and explicit continuity priorities.

Thundering herd and retry storm

Cause: Many clients release or retry together after a shared event, timeout, or recovery signal.

Mitigation: Use jitter, backoff, retry budgets, deduplication, admission controls, staged recovery, and correlated-demand tests.

Noisy-neighbor interference

Cause: One client or class consumes disproportionate capacity, state, bandwidth, or expert attention.

Mitigation: Add isolation, quotas, fair scheduling, protected capacity, and differential-service audits.

Head-of-line blocking

Cause: Slow or complex requests share one undifferentiated queue with short or urgent work.

Mitigation: Partition queues, classify service, cap work size, use deadline or fair scheduling, and surface blocked dependencies.

Ambiguous completion

Cause: A timeout or disconnect leaves client and provider unsure whether work occurred.

Mitigation: Use request fingerprints, idempotency, durable status, reconciliation endpoints, and explicit terminal states.

Interface leakage and client lock-in

Cause: Clients depend on provider internals, undocumented errors, timing quirks, or instance identity.

Mitigation: Test observable contracts, version deliberately, provide migration windows, and remove accidental dependencies.

Stateful affinity trap

Cause: Hidden session state binds a client to one provider instance or person.

Mitigation: Make state ownership explicit, externalize or replicate only where justified, define expiry and migration, and test failover.

Gatekeeping capture

Cause: The provider uses capability asymmetry to impose unrelated control, favoritism, rent extraction, or opaque exclusion.

Mitigation: Narrow authority, publish criteria, separate review and appeal, audit differential access, and preserve alternatives where possible.

Measurement blind spot

Cause: Only completed requests are measured while rejected, abandoned, deferred, or never-submitted demand disappears.

Mitigation: Measure the full request funnel, denied demand, abandonment, shadow channels, and client-class outcomes.

Overstandardization

Cause: The request contract suppresses legitimate context, exceptions, or professional judgment to simplify service.

Mitigation: Keep an explicit exception path, allow structured context, review edge cases, and separate routine from complex service classes.

Provider–client version fracture

Cause: The interface changes without compatibility, discovery, or migration support.

Mitigation: Use versioned contracts, compatibility tests, deprecation windows, client inventory, and rollback.

Fallback bypass becomes normal

Cause: Privileged clients use direct channels to avoid queue, validation, or accountability.

Mitigation: Log and limit exceptions, route recurrent exceptions into service redesign, and audit access by client class.

Centralization beyond necessity

Cause: The organization keeps moving capabilities into the provider after local ownership would be safer or more adaptive.

Mitigation: Periodically compare central, replicated, federated, and local alternatives using resilience, autonomy, cost, and context-fit criteria.

Neighbor distinctions

Hub-and-Spoke Coordination

Hub-and-Spoke Coordination reduces pairwise coordination by routing interactions through a hub. The hub may register, broker, clear, dispatch, or coordinate without owning the capability clients consume. This archetype requires direct provider-held capability plus client-initiated request and response.

Scale-Economy Consolidation

Scale-Economy Consolidation centralizes repeated or fixed-cost-heavy work to lower unit cost. Request–Response Capability Provisioning is justified by the reusable asymmetric service relation even when cost savings are not the primary objective.

Gateway Mediation

Gateway Mediation validates, translates, filters, or governs exchange across a boundary before forwarding it. A capability provider is the destination owner of the requested function, not merely the controlled crossing point.

Proxy Mediation

Proxy Mediation acts on behalf of another principal. Here the provider owns or operates the capability under its own service contract rather than representing a client or hidden counterparty.

Decoupling via Interface

Decoupling via Interface stabilizes a dependency boundary. It is a component here, but it does not require client initiation, one-to-many multiplexing, capability asymmetry, or shared-capacity governance.

Layered Abstraction

Layered Abstraction hides lower-level detail between adjacent layers. A client–server relation can cross layers or exist within one layer; its defining issue is addressable capability access, not hierarchy of abstraction.

Virtual Resource Abstraction

Virtual Resource Abstraction exposes logical resources over physical substrates. It may be delivered through this archetype, but virtualization is not required and the logical resource may be accessed by other relation patterns.

Service Rate Matching

Service Rate Matching adjusts capacity or cadence to arrivals so queues remain stable. It is an important supporting intervention after a shared service exists, not the relation that creates the service.

Load Balancing

Load Balancing distributes work among provider instances. It implements or scales a replicated variant but does not define client initiation, capability ownership, or response semantics.

Rate Limiting

Rate Limiting caps admission or request frequency. It protects the service boundary but is only one capacity-control mechanism inside the broader pattern.

Intake Queue Staging

Intake Queue Staging validates, classifies, prioritizes, or routes incoming work before full admission. It can operationalize the request boundary but does not establish the provider–client architecture.

Scalable Architecture Design

Scalable Architecture Design asks how structure grows without proportional fragility or cost. This archetype is one possible architecture whose scaling may require additional interventions.

Inversion of Control

Inversion of Control shifts initiative from the usual actor. Canonical client–server keeps initiation with the client; subscription or callback forms may introduce inversion only after explicit opt-in.

Examples

Example 1

A hospital network centralizes specialized pathology in an accredited laboratory: clinics submit orders and specimens, receive accession identifiers, and later receive validated results or explicit exceptions.

Example 2

A research institution exposes a high-cost microscopy core through a booking and sample-service interface with eligibility, preparation rules, queue classes, results, and maintenance outages.

Example 3

A software platform provides geocoding through a versioned API with authentication, quotas, request identifiers, errors, caching, and replicated service instances.

Example 4

A municipality provides permit review through an addressable office that receives applications, stages incomplete cases, assigns reviewers, returns decisions, and offers an appeal route.

Example 5

An organization provides payroll through a shared service that receives standardized departmental inputs and returns completed runs, validation errors, and correction status.

Example 6

A university advising center lets students initiate appointments or questions to a bounded expert team under fair access, urgency, and caseload policies.

Extended example

A regional diagnostic network has dozens of clinics that each need advanced molecular testing but cannot safely maintain the equipment, accreditation, rare expertise, and quality systems locally. The network creates one logical diagnostic service. Clinics discover it through a stable catalog, authenticate, submit structured orders and specimens, and receive accession identifiers. The service validates requests before admission, separates urgent and routine queues under published clinical criteria, isolates patient data, and measures arrival rates, processing time, rejected specimens, backlog, errors, and differential turnaround. Long-running tests use asynchronous status and terminal result messages rather than synchronous waiting. Replicated laboratory sites operate under one interface and quality contract, but each result identifies the authoritative site and method. If a site fails, work is rerouted only when chain-of-custody and method compatibility remain valid. Retries cannot create duplicate orders because requests carry stable identities. Clinics have a documented fallback for critical cases, and patients have accessible routes for correction and appeal. The design is not merely a shared-cost center: its defining structure is the addressable, client-initiated access to a provider-held diagnostic capability under explicit request, response, capacity, isolation, and failure rules.

Non-examples

• A broadcast notification system where the sender pushes alerts without a new client request.
• A peer-to-peer cooperative where every participant both supplies and consumes the same capability symmetrically.
• A central directory that only connects requesters to independent providers.
• A reverse proxy that filters and forwards traffic but does not own the requested capability.
• A local software library embedded in each client process.
• A consolidated procurement program whose primary intervention is bulk buying rather than an addressable request–response service.

Review note

No accepted archetype currently owns the complete request–response capability relation. Human review should focus on the naming boundary with Hub-and-Spoke Coordination and Scale-Economy Consolidation, the amount of capacity machinery retained in the parent, and the safeguards required when capability asymmetry creates essential-service power. The target prime is canonical and appears directly in identity.source_primes; no proposed primes were introduced.

Common Mechanisms

• API or RPC Endpoint — Exposes the capability as a stable, typed request/response surface at a fixed address, so any client can call it without knowing what happens behind it.
• Authentication Broker — Sits between clients and the capability, verifies who is asking, and issues a scoped, short-lived credential that grants exactly the access the request needs — and no more.
• Autoscaling Worker Pool — Keeps a pool of interchangeable workers sized to live demand — adding capacity as requests surge and releasing it as they ebb — so the service tracks load instead of over- or under-provisioning.
• Cache or Read Replica — Serves repeated or read-only requests from a synchronized copy placed close to demand, absorbing load that would otherwise hit — and overwhelm — the authoritative source.
• Central Registry — A single authoritative directory that maps a capability's name to where it lives and how to call it, so clients discover and bind to the provider by lookup instead of hard-wiring its location.
• Idempotent API — An interface that lets a client safely repeat a request: a duplicate carrying the same key returns the original result instead of executing the action a second time.
• Intake Portal — Gives every well-intended offer a single standard front door, so nothing reaches the team by side channel and the total volume of incoming help becomes visible in one place.
• Parallel Server Activation — Runs many interchangeable copies of the capability in parallel so requests are served concurrently — which requires pushing session state out of the instances so any copy can serve any request.
• Rate Limit with Burst Allowance — Lets inflow spike freely up to a bounded allowance but caps the sustained rate, so short bursts pass while a prolonged flood is throttled or shed before it exhausts the system.
• Safe Retry Protocol — A client-side procedure that retries a failed or uncertain request only through repeat-safe paths, with bounded attempts and backoff, so recovery doesn't turn into a self-inflicted overload.
• Service-Level Agreement — Pins a delegated service to measurable targets — response times, uptime, quality — with remedies the provider owes when the targets are missed.
• Service-Level Monitor — Continuously measures the live service against its promised targets — latency, error rate, throughput, backlog — and raises a signal the moment reality drifts past the line.
• Shared Service Desk — Concentrates a scarce human capability in one staffed team that many groups route their requests to, instead of each group hiring, duplicating, or hunting for the expertise itself.
• Ticketing System — Turns each incoming request into a durable, owned, trackable record that moves through states from open to resolved, so nothing is lost and everyone can see where it stands.
• Weighted Fair Queue — Serves competing requests in an order that gives each client or class a guaranteed share of capacity, so no stream is starved and none can monopolize the server.

Related Abstractions

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (5)

• Client Server Model: An asymmetric request-response relation in which one party holds a capability and many others initiate to consume it.
• Interface: A bounded, rule-governed surface across which two systems exchange information or control while hiding their internals, letting each evolve independently behind a stable contract.
• Multiplexing: Sharing one channel among many signals by dividing time, frequency, or code.
• Network: Models interactions between components.
• Resource Management: Allocation of finite assets.

Also references 24 related abstractions

• Abstract Data Type: Specify a component by its externally observable behaviour while suppressing its implementation, so any conforming implementation is interchangeable behind the contract.
• Access Control: Restrict system access.
• Authentication: Binding an asserted identity or origin to admissible evidence through a procedure that yields a verdict, before trust, access, or weight is granted.
• Boundedness: Values remain within limits.
• Caching: Store for faster retrieval.
• Capability Separation: Issuance is restricted to a privileged party while verification is open, tied by a forgery-prevention mechanism.
• Concurrency: Manage simultaneous processes.
• Consensus: Producing a single shared decided state from many participants with disagreeing or adversarial views, under a fault model, satisfying agreement, validity, and termination together.
• Consensus: Producing a single shared decided state from many participants with disagreeing or adversarial views, under a fault model, satisfying agreement, validity, and termination together.
• Constraint: Limits possibilities to guide outcomes.

▸ Show 14 more

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Stateless Request–Response Service · implementation variant · recognized

Processes each request from the supplied context without depending on hidden client-specific state retained from earlier requests.

• Distinct from parent: The parent permits both stateful and stateless service; this variant deliberately removes hidden session continuity.
• Use when: Provider instances should be substitutable and easy to replicate or recover; Requests can carry the context required for correct processing; Independent retry, caching, routing, and parallel service are valuable.
• Typical domains: software services, data services, public information, diagnostic tools
• Common mechanisms: api or rpc endpoint, idempotent api, safe retry protocol

Sessionful Capability Service · temporal variant · recognized

Maintains client-specific state across a sequence of requests so later responses depend on an established interaction context.

• Distinct from parent: This variant adds temporal affinity, session lifecycle, migration, expiration, privacy, and recovery obligations.
• Use when: Work is inherently multi-step and later requests depend on earlier state; Continuity, negotiation, progressive disclosure, or long-lived transactions are required; The cost of reconstructing context on every request is unsafe or excessive.
• Typical domains: clinical case management, customer support, interactive software, permit processing
• Common mechanisms: ticketing system, api or rpc endpoint, service level monitor

Asynchronous Queued Service · temporal variant · recognized

Acknowledges a request, stages it durably, and returns completion or failure later through a correlated channel.

• Distinct from parent: The parent includes synchronous service; this variant requires correlation, progress, cancellation, queue discipline, and terminal-state handling.
• Use when: Service time is long, variable, or dependent on scarce human or machine capacity; Clients should not remain synchronously blocked while work is performed; Demand bursts must be absorbed without treating admission as immediate completion.
• Typical domains: laboratory services, batch computing, public administration, specialist consulting
• Common mechanisms: ticketing system, weighted fair queue, service level monitor

Human Expert Capability Service · domain variant · recognized

Exposes scarce judgment, authority, craft, or expertise through a repeatable intake-and-response service for many requesters.

• Distinct from parent: The parent is substrate-neutral; this variant adds professional judgment, care, explanation, workload, and relational safeguards.
• Use when: The scarce capability is expert attention rather than automated computation; Requests vary in ambiguity and may require clarification or triage; Equitable access, caseload, and professional discretion must be governed.
• Typical domains: healthcare, legal services, research support, organizational operations, public administration
• Common mechanisms: shared service desk, intake portal, ticketing system, service level agreement

Replicated Capability Service · scale variant · recognized

Implements one logical provider through multiple service instances or sites so demand and failure can be distributed while the client sees a stable capability surface.

• Distinct from parent: The parent does not require replication; this variant adds routing, health, state replication, consistency, and failover decisions.
• Use when: One provider instance is a capacity or availability risk; Clients are geographically or organizationally distributed; The capability can be replicated with acceptable consistency and coordination cost.
• Typical domains: cloud services, distributed laboratories, regional shared services, content delivery
• Common mechanisms: central registry, parallel server activation, autoscaling worker pool, service level monitor

Near names: Client–Server Model, Client–Server Architecture, Addressable Capability Service, Multiplexed Capability Service, Provider–Consumer Request Pattern, Shared Capability Service.