Serverless patterns: delivery semantics before scale

Serverless removes server fleet management from the application team; it does not remove invocation types, retry policy, concurrency limits, durable state or data consistency. Draw the event source, queue, function, idempotency record, business store and failed-event destination as separate boundaries.

Invocation correctness

• A synchronous caller decides whether to retry after a timeout, when the function may have completed. Reuse a business idempotency key.
• Lambda asynchronous invocation and event-source mappings can deliver an event more than once. Consumers require an atomic claim and deterministic effects; object-store notifications are not a global exactly-once log.
• Bound retry age/count, configure redrive or failure destinations, and make replay an audited operation.
• Step Functions Standard and Express differ, and explicit task retries can repeat effects. “Workflow exactly once” is not permission to make payment or inventory APIs non-idempotent.

D1 consistency

D1 writes go to one primary. Read replicas update asynchronously. The Sessions API uses bookmarks to provide sequential consistency for the logical session; it is not blanket global strong consistency for arbitrary clients. Carry the bookmark across requests when read-your-writes matters.

Scenarios

Sources

• Lambda asynchronous retry behavior
• Lambda best practices
• Step Functions workflow types
• D1 read replication and sessions