Proposed flow for this scenario

  1. Customer request and stable operation ID
  2. Write durable job record
  3. Queue a reference to the job
  4. Worker updates completion conditionally
  5. Read result by customer and job

This flow describes a design to evaluate. The local experiment explores one stated mechanism. Its scope appears with the controls; the proposed services are not provisioned.

Decision checkpoints

ChoiceFits whenWatch for
DynamoDB base-table accessKnown partition-key lookups and bounded sort-key ranges dominate the request path.Hiding a table scan behind each customer request or assuming later reports require no new modeling.
RDS PostgreSQL/MySQLRelationships, changing joins and database-enforced relational rules are central to the product.Ignoring connection limits, migrations, availability and idle capacity.
Separate transactional and analytical pathsOperational requests and broad reporting have different access and freshness requirements.Adding duplicated data without ownership, lag and reconciliation rules.

Write down the requests before choosing the database

For this synthetic LetX design, a customer creates an export, checks its status and lists recent exports for one workspace. Record the exact identifiers, ordering, expected page size and permission boundary for each request. “We store JSON” does not distinguish a document-shaped value from the access pattern used to retrieve it.

A hypothetical key design can group workspace jobs under tenantId and order them with requestId or a deliberately sortable job key. Decide whether a status lookup starts with the complete key or needs another index. The local simulator supports only the base table; a real index design introduces additional write, storage and consistency considerations that this console does not measure.

The question that changes the answer

Now QuantumSketch needs reports combining projects, collaborators, subscription states and render outcomes, with filters that change each month. PostgreSQL is a reasonable candidate when joins and relational constraints are a central part of that product. This is a design inference from the scenario, not a benchmark or a rule that small apps must use SQL.

DynamoDB can represent relationships through intentional access-oriented modeling, and it supports real transactions. It does not provide a relational JOIN operator. Do not describe the choice as “SQL has transactions, NoSQL does not.” Ask which consistency boundary and query shape each operation needs, and whether the application can maintain the proposed derived records.

Query and Scan solve different requests

A DynamoDB Query starts from partition-key equality and can narrow a sort-key range. A filter removes results after the page has been evaluated; it does not turn a broad read into a key lookup. In the local console, try a Scan with Limit 1 and a filter that excludes the first item. An empty result can still carry a cursor because another page remains.

Use that exercise to distinguish returned items from evaluated items. It does not benchmark DynamoDB or calculate AWS read charges. A real access-pattern review must examine request sizes, consistency choices, indexes and uneven key traffic. A large workspace can become a concentration of load even when the average customer is small.

Correctness and recovery come before scaling claims

A retried LetX job should not silently replace a completed job. Practice attribute_not_exists on its stable key, then repeat the request and inspect the conditional failure. For edits, use a version condition when stale updates must be refused. Real multi-record invariants may require transactions or a different model; the local implementation does not support transaction APIs.

For RDS, separate connectivity from data correctness. A private path can pass its security-group and ACL checks while a selected read replica remains unsuitable for writes. A Multi-AZ DB-instance standby provides failover capacity, not a customer read endpoint. Backups, restore drills and application reconnection behavior remain separate requirements. The simulator stores configuration only, so a successful local snapshot restore cannot prove recovery of customer data.

Cost, privacy and an exit plan

Estimate request and storage volumes for the key-value design and provisioned capacity, storage, I/O and availability needs for the relational design. Include backups, data transfer and supporting network components where applicable. Use current regional pricing with your workload inputs; there is no universal free or cheapest choice.

Tenant isolation belongs in the application and permission design. Avoid putting customer contents into diagnostic logs merely because they are convenient to inspect. Define migrations, export formats and who owns each record before introducing another database for reporting. Extra stores can be useful, but each one adds a synchronization and recovery obligation.

Original scenario question

LetX initially reads one job by tenantId and requestId. A new support feature must list every failed job across every workspace, ordered by completion time. Does adding a filter to the existing customer Query solve that requirement?

No. That Query is still limited to one partition-key value. Revisit the access pattern: an intentional index or reporting pipeline may fit, or a relational query may be preferable depending on the broader product. Explain freshness, tenant access and write consequences before selecting the alternative. The retry experiment below illustrates repeated work; it does not execute or benchmark either database.

Practice the supported console workflow

SimAWS · ShahriarLabs

Predict it. Test it. Change one thing.

Local educational model. No account or cloud charges. Nothing is deployed to AWS.

Worst-case downstream attempts per initial request: 27.

Nested retries multiply attempts in the worst case. Backoff and jitter change timing; they do not reduce this configured upper bound. Real failures need an end-to-end retry budget.

sim.shahriarlabs.com · Free to explore

Sources and scope

Reviewed against these official references. The model’s supported scope appears alongside its controls.

How we review explanations