What this prompt does
This prompt designs an event-driven architecture on AWS messaging services for a given [application_type]. It defines an event taxonomy for [event_types] using a [schema_standard], sets up SNS topics for [topic_categories] with filtering, configures SQS queues for [consumer_services] with a [visibility_timeout] and [retention_period], and wires EventBridge rules to match [event_patterns]. The whole flow is built so events fan out cleanly and consumers process independently.
The structure works because it makes the model design the parts engineers skip under time pressure. It forces dead-letter queues with a [max_receive_count] plus a Lambda that processes DLQ messages and alerts [alert_channel], FIFO queues for [ordered_events] grouped by [grouping_strategy], and exactly-once processing via [idempotency_strategy]. A redelivered message corrupting state is the failure mode I least want to debug in production, so making idempotency and DLQ handling explicit is the point of the prompt.
When to use it
- A system has outgrown synchronous calls and needs decoupled, retry-safe messaging
- You are building a pipeline like order processing where
[event_types]must flow between independent services - You need SNS-to-SQS fan-out with filtering so
[consumer_services]receive only relevant events - You want dead-letter handling designed properly, with a
[max_receive_count]and DLQ processing - Certain
[ordered_events]require FIFO ordering and deduplication keyed by[grouping_strategy] - You need idempotent consumers so message redelivery never corrupts state
Example output
Expect an architecture spec: an event-schema definition for your event types, SNS topic and filter-policy configuration, SQS queue settings with visibility timeout and retention, a DLQ design with a processing Lambda and alerting, FIFO configuration for ordered events, EventBridge rules for your patterns, an idempotency implementation, and CloudWatch dashboards for queue depth, oldest-message age, and DLQ counts.
Pro tips
- Set
[visibility_timeout]relative to your consumer's processing time — the default of roughly six times the Lambda timeout prevents premature redelivery while work is still in flight - Define
[event_types]with versioning from day one; adding a version field now saves painful schema migrations later - Choose
[grouping_strategy]carefully for FIFO — grouping by order ID preserves per-order ordering while still allowing parallelism across different orders - Make
[idempotency_strategy]concrete, such as a DynamoDB table keyed on event ID, because exactly-once is really at-least-once delivery plus deduplication you implement - Set
[max_receive_count]so genuinely poisoned messages land in the DLQ instead of looping forever, and actually wire the DLQ alert to[alert_channel] - Validate the design against your real throughput; the model proposes settings, but queue depth and retention need tuning under your actual load
- Use SNS message filtering on
[topic_categories]so each consumer subscribes only to events it cares about, rather than filtering in application code after delivery - Set the DLQ processing Lambda to capture enough context — original payload, error, and receive count — so a message in
[alert_channel]is actually debuggable - Watch the CloudWatch oldest-message-age metric closely, since a steadily rising value signals a consumer falling behind before queue depth makes it obvious
