Cloud Service Integrations
Cloud adapters should optimize for bounded cost, predictable quotas, and clear failure semantics under provider throttling.
This is conceptual guidance. A public cloud-service adapter reference is not published yet.
On this page
Jump to a section
Use the outline to move through longer pages without losing your place.
Related reading
Read the formal docs
The protocol-level details for quotas, batches, and output contracts live in the deeper documentation set.
Explore more patterns
These neighboring patterns show how similar controls change with server, app, OS, and web surfaces.
When this pattern fits
Best fit
- The source system is a remote API where quotas, retries, and pagination shape the user experience.
- You need a contract that normalizes provider transport details into stable operations.
- Structured errors and explicit rate-limit posture are central design concerns.
Watch for
- Provider-specific failures leaking through without clean protocol-level mapping.
- Read-heavy list operations that need pagination and field-selection discipline.
- Batch or fan-out behavior that can amplify cost or exhaust quotas unexpectedly.
Design Guidance
Operational Controls
- Expose pagination and limit controls consistently.
- Separate read/list from state-changing operations.
- Return provider-context metadata in structured errors.
Resilience
- Document retryability per operation.
- Surface rate-limit and quota conditions explicitly.
- Bound batch and fan-out behavior to avoid exhaustion.
Conceptual Example
{
"operation": "list_instances",
"params": {
"region": "us-east-1",
"limit": 50
}
}
Implementation Reference
Universal Runtime
Map quotas, request construction, response parsing, and structured error handling to a real runtime model.
Testing Guide
Exercise retry assumptions, route validation, and integration coverage before exposing a remote API broadly.
Plugin System
Use the plugin pipeline docs when auth, transport, serialization, or transformation concerns need clean isolation.