AWS-DB-Study

1 · DSQL write conflict at commit

Two regions update the same product row within one second. Under snapshot isolation with optimistic concurrency, what does each transaction observe, which one wins, and what must the loser do? Where does the retry belong — client, driver, or middleware?

Answer: each sees its own snapshot; first committer wins at adjudication; loser gets a conflict error and retries the whole transaction (idempotent retry with backoff+jitter). Retry belongs in the app's transaction wrapper, not the driver — only the app knows the unit of work. Trap: retrying blindly on non-idempotent writes.

2 · Connection math before bigger instance

200 app pods, pool size 25 each, DSQL cap 10k connections. Is the database the problem? Show the math and the fix order.

Answer: 200 × 25 = 5,000 — under the cap, so look at top-SQL/wait events first, not tier size. Fix order: pool right-size → transaction scope/timeouts → top-query EXPLAIN → only then capacity. Trap: scaling the tier for a pooling bug.

3 · Oracle→DSQL migration triage

SCT flags 40 PL/SQL packages, sequences, and dblinks. Rank what blocks cutover vs what can go post-launch, and name the replication shape for the transition window.

Answer: blockers = correctness items (sequences→identity semantics, dblinks→app-side joins, unsupported types). Post-launch = perf tuning of converted procedures. Transition = DMS full load + ongoing CDC with validation, cutover with rollback snapshot. Trap: declaring victory at 100% SCT conversion without a CDC-tested rollback.

Daily say-aloud reps

• "Understand. Prepare. Identify. Support. Data first, trap ruled out, fix that stays fixed."
• "Two active Regions plus witness gives quorum without losing writes — RPO zero, RTO minutes."
• "Conflicts are adjudicated at commit; the loser retries the whole transaction."
• "Same 403 to the client — explicit Deny, IAM, bucket policy, KMS key policy, or SCP. I check in that order."
• "In Oracle I did X with [tool]; in AWS I get the same outcome with [service], and the difference I watch for is [trap]."

Drill 1 · Slow-query triage from EXPLAIN

Given EXPLAIN (ANALYZE, BUFFERS) showing Seq Scan on 40M rows, Buffers shared hit=12 read=380k, and a nested loop over it — narrate: top line first, the one fix with biggest payoff, and what you re-measure.

Bug → risk → fix → test. Fix: composite index on the filter+join columns (equality first, range last). Re-measure: execution time + buffers hit ratio for that query hash in Performance Insights.

Drill 2 · Buggy retry client

for row in orders:
    try: db.exec("UPDATE stock SET qty = qty - 1 WHERE id=%s", row)
    except: pass  # retry later

Name every bug, its production risk, the fix, and one test case each — before editing.

Bugs: swallowed exceptions (silent data loss) · no idempotency key (double-decrement on retry) · no transaction boundary · no backoff/jitter (retry storm) · no timeout. On DSQL add: whole-transaction retry on conflict error, not per-statement.

Drill 3 · Pool sizing math

Service runs 60 tasks × pool 20 against RDS max_connections 400. p95 spikes at deploy. Compute headroom, state the fix, and the CloudWatch metric that proves it.

60 × 20 = 1,200 demand vs 400 cap — 3× over. Fix: centralize pooling (RDS Proxy) or cut per-task pool to ≤5 with queueing. Prove with DatabaseConnections + p95 latency back inside SLO for a full traffic cycle.