> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Worked Examples > Compare application-level adapter choices, including delivery, shared capacity and recovery responsibilities. A backend decision rarely affects only one API. An order worker depends on a database and a queue; a customer-controlled deployment may share a database across several adapters. Evaluate those relationships before choosing each service independently. The workloads below are illustrative. Each compares candidate architectures against the same requirements without recommending a preferred backend. They are not benchmark results or promised cost savings. A service adapter includes both the origin service and its target service (backend), so each composition below combines several directed mappings. ## General trade-offs Hold the target environment and application requirements constant while comparing architectures. A database offered in another cloud is not a candidate when the customer requires all data to stay in the selected environment. Likewise, the option to operate a private Kubernetes cluster is a separate placement and responsibility decision, not an implicit property of a managed cloud service. Within each environment below, identify the backend for every origin service, the capacity those services share and the failure cases that span them. Use the same workload and correctness checks for both candidates. More independent services can separate capacity and failures but add operational interfaces; consolidating on one engine can reuse operating knowledge but also concentrate contention and recovery work. ## Microsoft Azure ### Order processing: backend choices An application uses DynamoDB for order records, SQS for background work and S3 for receipts. The customer requires Azure placement and managed backend services. Workers process independent jobs and may receive the same job more than once. Order changes use conditional updates; this example does not require a multi-item DynamoDB transaction. Within the Azure mappings, use **provisioned Cosmos DB** for this DynamoDB example and **Blob Storage** for S3 receipts. Compare **Service Bus** with **Azure Database for PostgreSQL Flexible Server** as the SQS backend. Keeping the database and object mappings constant isolates the queue choice; this does not imply a PostgreSQL-backed DynamoDB mapping in the Azure catalog. Service Bus provides native messaging infrastructure; the PostgreSQL mapping represents queue state in a database. Service Bus fits teams that want queue capacity and operations separate from a database. PostgreSQL fits teams prepared to size and operate the queue's tables, connections and write workload using their database practices. Neither choice makes Cosmos DB writes and queue acknowledgements atomic. | Decision | Cosmos DB + Service Bus | Cosmos DB + PostgreSQL-backed queues | | ----------------------- | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | | Capacity | Budget database request units separately from queue capacity and worker concurrency. | Budget Cosmos DB request units separately from queue-database connections, write activity, indexes and backlog storage. | | Operating model | Native message-service configuration and alerting alongside Cosmos DB. | PostgreSQL queue-table maintenance and recovery alongside Cosmos DB. | | Failure handling | Coordinate database results with Service Bus delivery and acknowledgement. | Coordinate database results with the queue contract; do not assume one transaction spans both adapters. | | Qualification questions | Do native delivery behavior and queue capacity meet the workload's requirements? | Can the team operate the queue database within its capacity and recovery budgets? | Read the directed [Cosmos DynamoDB](/cloud-adapter/service-catalog/aws/databases-storage/dynamodb-table#on-azure), [SQS standard](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic#on-azure) and [S3](/cloud-adapter/service-catalog/aws/databases-storage/s3#on-azure) profiles. The actual conditional update, index and receipt operations must fit the chosen mappings. Compare queue-specific strengths and constraints in [SQS trade-offs](/cloud-adapter/trade-offs/aws-sqs#microsoft-azure). ### Follow a job across the commit boundary Suppose a worker updates an order, calls an external payment system and then deletes the queue message. It can stop after a successful payment but before the queue acknowledgement. Another worker can receive that job. The application needs a stable business job identity and an idempotent payment operation, together with a durable record of the workflow outcome. Queue deduplication cannot undo an external charge, and a transaction on the order table cannot include a payment provider that is outside that transaction. Create one test order and a job carrying its stable operation ID. The payment stub records that ID and returns the same logical result on retries. Keep production payment credentials out of this test. Let the worker perform the effect and record its result, then interrupt the test worker before it deletes the queue message. Preserve the message identity, order state and stub's operation record. Allow the configured delivery lease to expire and process the job again. The expected business outcome is one charge identity and one completed order, even if the handler runs twice. Verify those records independently of the queue response. A second charge means the workflow's idempotency boundary is incomplete. Investigate the application operation ID, payment behavior and durable outcome record before changing queue settings. Remove only the test order, messages, receipt objects and stub records after preserving redacted evidence. An [executed explanation](/cloud-adapter/debugging/explain) can describe the adapter path for an individual request. It does not prove that all three services and an external payment system reached a globally atomic outcome. ### Capacity, ownership and exit The customer platform team owns native resource configuration, capacity alerts, credentials and recovery access. For the PostgreSQL queue alternative, this includes queue-database sizing, backup policy, maintenance planning and restore initiation. The vendor application team owns the job identity and workflow reconciliation procedure. The cloud provider operates its managed service infrastructure. Agree who operates and upgrades the adapter process as a separate responsibility. For the Cosmos candidate, the [provisioned Cosmos configuration example](/cloud-adapter/configuration/examples#dynamodb-to-provisioned-azure-cosmos-db) illustrates its capacity settings. [DynamoDB tuning](/cloud-adapter/tuning/aws-dynamodb) covers the target-specific controls. For either composition, identify the physical capacity owner before expecting two logical tables to have independent budgets. For migration, provision the destination and verify it before routing new work there. Account for in-flight jobs and writes accepted during the cutover. Keep acknowledgement paths for messages already received from the old queue; an old receipt is not a portable acknowledgement token for a new backend. **Comparison record:** Azure placement; independent jobs; conditional order updates. Hold provisioned Cosmos DB and Blob Storage constant while comparing Service Bus with PostgreSQL-backed SQS. Record contract eligibility, queue capacity cost and operating owners for each composition. Release qualification requires one logical payment across the commit-before-ack failure, plus recovery checks for each durable store. ## Google Cloud ### Intermittent tenant metadata: backend choices A synchronous HTTP handler reads tenant settings, looks up users by a supported secondary key and conditionally updates metadata. Traffic is intermittent, with quiet periods. The data does not require exact arbitrary-precision financial decimals. Compare **Firestore with Cloud Run execution** against **Cloud SQL PostgreSQL with Cloud Run execution**. Check the operation, numeric and index contract of each mapping. Keep the function runtime constant so the database comparison measures a database decision rather than two unrelated changes at once. The application keeps its DynamoDB request shapes and its handler's business logic. Cloud Adapter supplies the selected DynamoDB mapping; Cloud Run executes the function through the selected Lambda mapping. Review the [DynamoDB profile](/cloud-adapter/service-catalog/aws/databases-storage/dynamodb-table#on-google-cloud) and [Lambda profile](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#on-google-cloud) separately. ### Compare cost and behavior Firestore charges for document and index work under its capacity model. Guarded updates, contention and the lookup pattern affect the total work performed, including during traffic bursts. Quiet periods alone do not establish its total cost relative to a provisioned database. Cloud SQL has a provisioned capacity floor, connection limits and database maintenance responsibilities, alongside its mapping's numeric and transaction behavior. Existing database capacity and operating expertise affect that budget, but do not establish compatibility. Firestore's cross-document transaction capability should not be dismissed simply because it is a document store. Compare the actual transaction and numeric requirements in [Trade-offs in AWS DynamoDB](/cloud-adapter/trade-offs/aws-dynamodb). Declare and prepare the required indexes through the mapping's documented provisioning path. Do not assume that adding a GSI to a runtime `CreateTable` call provisions every required target index. ### Choose function warmth independently A low average request rate does not establish whether users can tolerate startup latency. Run the handler with its actual image and dependencies, record the application's latency budget, and measure the first request after idle and a burst beyond the warm capacity. A warm execution floor may be appropriate even when the database uses consumption-oriented capacity. Conversely, paying for a provisioned database does not require keeping every function instance warm. Include downstream connections and admitted concurrency in the function decision. ### Qualify and migrate Use a disposable tenant containing the same field types and key patterns as the application. Check a conditional update and the supported alternate-key lookup against an independently recorded expected result. Then change the traffic from distributed tenants to a hot tenant and inspect retries, added operations and completed-request latency. The expected correctness result is the same tenant data and documented lookup behavior under both traffic shapes. Higher contention may change latency and cost. If an incorrect value appears, investigate the mapping and request before treating it as a capacity issue. Google operates the managed storage and execution infrastructure. The named deployment operating team owns runtime configuration and alerts; the application team owns index rollout, retry behavior and acceptance after recovery. Stop load generators and remove only the disposable tenant's data and test execution resources when finished. Migration must recreate required indexes, copy data, catch up writes and verify lookups before traffic moves. Reverting the endpoint does not move back writes accepted by the new database. **Comparison record:** Google Cloud placement; intermittent metadata, supported lookups and conditional updates. Compare Firestore document/index work with Cloud SQL provisioned capacity, connections and maintenance under the same traffic trace. Record numeric and index compatibility separately from cost. Test each eligible mapping with Cloud Run held constant, and choose the warm floor from the application's measured latency budget, not the database's billing model. No database is preferred in advance. ## Private Kubernetes ### Data and queues: deployment choices A customer permits only private Kubernetes and has a PostgreSQL operating team. Public managed databases are not eligible. The application needs DynamoDB-backed data and SQS-backed jobs, both served through their PostgreSQL mappings. The comparison is **separate PostgreSQL instances** versus **separate databases on one shared instance**. These are deployment topologies, not invented backend service names. Evaluate how queue backlog, maintenance and recovery affect the transaction workload under each topology. | Boundary | Separate instances | Shared instance | | ---------- | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | Capacity | Size and monitor each workload independently. | Budget their combined connections, write activity and storage. | | Failure | A database-instance outage need not stop both workloads; shared cluster dependencies can still affect both. | An instance outage affects both data and work delivery. | | Operations | More resources, backups and upgrades to manage. | Fewer instances, with more coordination between workload owners. | | Recovery | Coordinate separate recovery points and in-flight work. | A shared backup can simplify some operations, but does not create application-level atomicity. | Separate database names on a shared instance do not provide independent CPU, storage or failure boundaries. Check the actual infrastructure beneath the chosen names. ### Verify isolation and recovery Drive a bounded queue backlog in a disposable environment while measuring successful database transactions. Compare latency and error rates with the application's stated budget. If queue pressure harms that budget, adjust the capacity or isolation design before increasing worker concurrency. Next, restore application data and the delivery state needed to resume work. Reconcile messages whose effects may have committed before their acknowledgement. Verify both unprocessed jobs and jobs already recorded as complete. Count the time until the application can safely process work, not merely the time until PostgreSQL accepts connections. The customer platform team owns databases, storage, backups, adapter upgrades and recovery access. The vendor defines business correctness and participates in cutover and recovery acceptance. [Operations](/cloud-adapter/operations/overview) should name the alert recipient and restore authority for this deployment. For a shared instance, measure combined capacity demand and explicitly assess correlated outages and contention. For separate instances, measure each capacity budget and the additional backup, upgrade and recovery work. Keep separate database credentials and explicit resource ownership even when the physical instance is shared. **Comparison record:** private infrastructure, no public-cloud data service, existing PostgreSQL operators. Test separate and shared instances against the same pressure and restore budgets. Record additional operations and capacity cost for separate instances, and contention and correlated-failure consequences for a shared instance. Migration in either direction includes data and backlog transfer, in-flight reconciliation and a cutback plan for new writes. ## Next steps Use [Validating Your Choice](/cloud-adapter/trade-offs/validating-your-choice) to record the contract, available evidence and workload checks. Then follow the concrete startup and validation steps in the [DynamoDB](/cloud-adapter/trade-offs/aws-dynamodb) or [SQS](/cloud-adapter/trade-offs/aws-sqs) article.