Cloud-Native NoSQL

Lambda reuses the execution environment (container) between invocations as long as traffic continues. Code outside the handler function runs only during a cold start — the container initialisation. By placing the DynamoDB resource outside the handler, you pay the 142ms initialisation cost once and then get sub-5ms DynamoDB access on every subsequent warm invocation. Moving it inside the handler would reinitialise boto3 on every single call — a 10–50ms tax on 100% of your requests.

Lambda has at-least-once delivery semantics — if a function times out or a network error causes the caller to retry, the same event can be delivered twice. Without the condition, you write duplicate click events. With attribute_not_exists(SK), DynamoDB rejects the write if the item already exists — the second invocation is a no-op. This makes the function idempotent: safe to call multiple times with the same input and always produce the same result.

AWS Lambda injects a unique aws_request_id into every invocation's context object. Using it as the sort key guarantees uniqueness — no two invocations share the same request ID. On a retry, the same aws_request_id is reused by the Lambda runtime, so the attribute_not_exists condition catches the duplicate and prevents the double write.

DynamoDB Streams delivers every change as one of three event types. NewImage contains the item state after the change; OldImage contains it before. For INSERT, only NewImage exists. For REMOVE, only OldImage exists. For MODIFY, both are present — letting you compute exactly what changed. You configure which images to include when you enable Streams: NEW_IMAGE, OLD_IMAGE, NEW_AND_OLD_IMAGES, or KEYS_ONLY.

If the product was never indexed in Elasticsearch — because it was created and deleted before the stream processor caught up, or because indexing failed earlier — the delete would throw a 404. Passing ignore=[404] silences this error and treats the delete as a no-op. The end state is the same: the document does not exist in Elasticsearch. Always design stream processors to be idempotent and tolerant of partial state.

DynamoDB Streams delivers records near-real-time but not synchronously — there is typically 100–300ms of propagation delay. For inventory search, 200ms is completely acceptable. For a banking ledger where both systems must be in sync before a transaction is confirmed, this async pattern is not appropriate — you would need a synchronous dual-write with a transaction, not a stream.

When two users in different regions update the same item within the same second, DynamoDB uses last-write-wins based on wall-clock time. The write with the later timestamp wins — the other write is silently discarded. For most user profile and session data this is acceptable. For financial data where every write must be preserved, last-write-wins is not appropriate — use a single-region write anchor with multi-region read replicas instead.

A write in Singapore takes about 900ms to appear in Virginia. If a user in Singapore updates their profile and then a process in Virginia reads it 500ms later, it will read the old value. This is eventual consistency across regions. Design your application to tolerate this: use region-local reads for user-facing operations, and avoid cross-region read-after-write patterns for data the user just modified.

When us-east-1 goes down, the application in eu-west-1 and ap-southeast-1 continues using its local DynamoDB replica — it never knew about the Virginia outage. There is no DNS failover to configure, no connection string to change, no circuit breaker to trip. The regional isolation is built into the architecture. This is the defining advantage of active-active global distribution over traditional primary-secondary replication.

Parameterising the table name with the environment variable lets the same Terraform module deploy identical infrastructure to dev, staging, and production — with different names so they do not collide. terraform apply -var="environment=staging" creates UserEvents-staging. This is the foundation of environment parity: every environment is created from the same definition, eliminating "works in dev, fails in production" configuration drift.

Terraform requires you to declare every attribute used in a key (primary or GSI) in an attribute block — even if those attributes are only used in the GSI. You do not declare all your item attributes here, only the key attributes. If you reference eventType in a GSI but forget the attribute block, Terraform will error with a validation failure before creating anything.

One line in Terraform activates a 35-day continuous backup window. Without it, your only recovery option after an accidental mass delete is the most recent on-demand backup — potentially hours old. With it, you can restore to any second in the past 35 days. In a code review, this line is visible, discussable, and mergeable. A forgotten checkbox in the AWS console is invisible until the incident.