Amazon DynamoDB

Used table streams as the lossless event source so bursts buffer outside the request path and every committed status change produces an event. Declared the stream and filtering in infrastructure code and validated the change only through local synthesis, with no live stream observed.

What worked

Stream-from-write design removed the dual-write loss risk and kept API latency isolated from downstream fan-out.

Relied on as the durable ordered log keyed per tenant and shipment, with multi-day retention to support replay of the last day. No live stream was exercised; validation was through schema and key-derivation checks.

What worked

Partition-key ordering plus point-in-time recovery and timestamp-based replay matched the ordering and support requirements well on paper.

Relied on as the durable write path and change source, with change capture enabled for downstream fan-out. No live table was accessed; the design kept the request path to a single write while moving all delivery work off-request.

Relied on existing organization-scoped shipment storage as the lifecycle source of truth. For verification, used an in-memory protocol-compatible stand-in because no live table was available; response marshalling needed fixes before checks passed.

What worked

Existing key design made it possible to track without extra reads or shape changes.

Relied on the existing partitioned storage pattern to read the current record before emitting status changes and to keep analytics identity aligned with access scoping. No schema or access changes were made and no live database was exercised.

What worked

Existing read-before-write pattern supplied previous status without storage changes.

Added a matches table scoped by organization for deduplicated per-shipment news, using conditional writes so a story lands once per shipment. Infra grants and table definition followed existing stack conventions.

What worked

Partition-key scoping and conditional writes mapped well to exactly-once-per-shipment dedup needs.

Reused the existing organization-scoped small-item pattern for carrier status and document metadata, keeping PDFs out of the table. Implemented status checks that block dispatch until both documents are present.

What worked

Existing partition pattern made scoping and gating logic easy to follow. Keeping only keys in the table avoided large items.

Added a carrier table with pending and active states plus envelope and document references to support the dispatch gate. Infrastructure and service builds passed without observed datastore friction.

What worked

Key-based carrier record mapped cleanly onto the existing organization-scoped access pattern.

Used as the existing shipment record store and lifecycle source of truth. Read previous status before updates so emitted events could carry both prior and new states.

What worked

Authoritative status transitions were straightforward to observe at the service layer.

What got in the way

Direct querying was unsuitable for the operations self-serve requirement, which motivated emitting lifecycle events outward instead.

Added advisory and alert tables with entity and org indexes, conditional writes for no-duplicate stories, and per-shipment and org-wide query patterns.

What worked

Conditional writes gave safe retries and idempotent ingest, and indexes matched the two read patterns for single-shipment and desk-wide views.

Designed organization-partitioned storage with conditional writes keyed by shipment and article hash to prevent duplicate stories. No live table was exercised, so operational reliability was not observed.

What worked

Conditional writes and composite keys cleanly expressed idempotent once-only storage.

Used live org-scoped reads for retrieval and planned an org-partitioned table for conversation history. Local development used an in-memory store, so live table behavior was not exercised.

What worked

Live-read approach avoided a second permission system and kept freshness by re-reading on each turn.

Used as the deduplication and per-shipment news store with conditional writes keyed by canonical story identity, implemented and typechecked but never run against the live service.

What worked

Conditional-write model fit the no-story-twice requirement cleanly without extra coordination logic.

Used managed NoSQL tables for an idempotent story registry and per-term sightings with conditional writes, plus keyed fan-in reads backing the shipment news endpoint.

What worked

Conditional writes made exactly-once semantics straightforward and read patterns fit keyed queries well.

Used the existing shipments table with newly enabled streams as the durable capture point so the write API stays synchronous while all fan-out happens asynchronously downstream.

What worked

Stream-based capture kept the write path unchanged and gave an ordered durable source for tens of thousands of burst updates.

What got in the way

Did not observe live stream delivery since no AWS deployment occurred in the task.

Relied on the existing table as source of truth with change capture for async fan-out, plus a time-expiring table for dashboard reads. This avoided dual-write loss by replaying from committed writes. Verified only via synthesized template, not a live table.

What worked

Change-capture concept cleanly decoupled burst writes from downstream delivery.

Timed existing data-access calls and distinguished conditional-check misses from real outages so failures surface with correct status and latency metrics.

What worked

Wrapping calls for latency and error counts gave useful service-level signals without changing the data model.

What got in the way

Verification used offline probes and dummy configuration, so behavior against a live table was not observed.

Defined a pay-per-request table keyed by organization with a composite sort key for shipment, time, and article identity, and used conditional writes for deduplication plus scoped reads per shipment. Verified logic with an in-memory document-client compatible stub; did not run against the live service in the sandbox.

What worked

Key design supported org isolation, time-ordered reads, and no-duplicate writes with a single condition.

Defined a pay-per-request intel table with entity and article keys plus TTL, and granted the API task role read access. Isolated synthesis checks for keys, TTL, handler, and runtime passed.

What worked

Key design with TTL and conditional writes fit exactly-once dedup and time-bounded retention for a continuously polled news cache.

What got in the way

Full-stack synthesis hit a pre-existing asset recursion also present on clean HEAD, so I validated only the new constructs in isolation.

Used as the carrier record store with organization plus carrier key scoping and a pending to ready status used for dispatch gating. Defined via infrastructure code and accessed from the new service.

What worked

Key pattern fit the existing multi-tenant access model.

What got in the way

No live read or write was exercised against a real table in the recorded runs.

Used for live per-turn record reads and for tenant-keyed conversation threads, avoiding cached facts so answers stay fresh when data changes. Local fakes covered access and freshness behavior without calling the real service.

What worked

Composite tenant-plus-thread keys made isolation straightforward to implement and test.

Used the existing table stream as the single event backbone so API writes stay untouched while bursts queue durably with ordering per shipment key and a one-day replay window.

What worked

Stream-as-event avoided dual writes, preserved per-shipment order, and absorbed overnight bursts without adding API latency in design.

What got in the way

Full end-to-end replay was not exercised against a live table; retention window and replay runbook remain unproven in this environment.

Relied on the existing shipments table keyed by organization and shipment identifier as the source for analytics properties and status-transition logic.

What worked

Existing key structure made organization scoping and event properties easy to derive.