Day 5 - Week 11 Review: The Questions That Divide the Messaging Models

Payment transactions must be processed in per-customer order, without duplicates, exactly once. About 4,000 occur per second. What is an appropriate configuration?

• APut an idempotent consumer on an SQS Standard queue and reorder per customer in the application using sequence numbers
• BA high-throughput FIFO queue + using the customer ID as the message group ID
• CA FIFO queue with the same single group ID on all messages to force global ordering
• DPut the customer ID as the partition key on a single Kinesis Data Streams shard to guarantee ordering

One S3 object upload must trigger three tasks - thumbnail generation, virus scanning, and search indexing - independently (the failure of one task must not affect the others). What is the most canonical pattern?

• AS3 event → a single Lambda that runs thumbnail, virus scan, and indexing sequentially wrapped in try/catch
• BS3 → SNS → fan-out to three SQS queues (each with a Lambda)
• CS3 → a single SQS → a Lambda receives the message, performs all three tasks, and acks
• DReplicate-upload the same object to three buckets so each bucket's event triggers one task

You want to run real-time anomaly detection on a clickstream with Lambda while also archiving all the raw data to S3 for later analysis with Athena. What is an appropriate configuration?

• AAttach two consumers, an anomaly detection Lambda and an archive Lambda, to a single SQS queue so both receive the same message
• BConnect a Lambda consumer and a Firehose consumer to Kinesis Data Streams at the same time (Firehose → S3)
• CSNS topic → fan out to a detection SQS and an archive SQS, sending to Lambda and S3 respectively
• DCapture clicks table changes with DynamoDB Streams and do Lambda detection and S3 loading at the same time

You are loading logs into S3 with Firehose and there is a complaint that "data arrives about a minute late." If sub-1-second real-time processing is mandatory, what should you do?

• AIncrease the Firehose buffer size to 128 MB so more is flushed at once and arrival is faster
• BChange to consuming Kinesis Data Streams directly (Lambda/EFO)
• CSet the Firehose buffer interval to 0 seconds so delivery is immediate
• DSwitch the front end of Firehose to SQS and process within 1 second with a short visibility timeout

While pushing directly to Lambda through SNS, notifications published while Lambda was briefly down were permanently lost. How do you secure durability?

• ASet the SNS topic's message retention period to 7 days so messages are redelivered after Lambda recovers
• BChange to SNS → SQS → Lambda so SQS retains the messages
• CIncrease Lambda reserved concurrency to reduce downtime and secure retry throughput
• DThrottle the SNS publishing rate so only as much as Lambda can handle is sent, preventing loss

In a Kinesis stream, only a particular shard throws ProvisionedThroughputExceededException while other shards sit idle. What are the cause and the fix?

• AThe retention period is short so records expired - fix by extending retention from 24 hours to 7 days
• BA hot shard from partition key skew - raise key cardinality to distribute evenly
• CRead contention because the consumer does not use EFO - enable EFO to resolve the write throttle
• DCapacity is blocked because it is not On-Demand mode - switch from On-Demand to Provisioned

You need to run multiple Lambdas in order, compensate (roll back) earlier steps upon a mid-way failure, and let operators trace the entire flow visually. What is an appropriate service?

• AA chain where one Lambda invokes the next Lambda directly + calling compensating Lambdas in reverse order on failure
• BStep Functions (Retry/Catch + Saga compensation)
• CA chain with an SQS queue per step where a Lambda passes a message to the next queue when it finishes
• DA chain that routes each step's completion event to the next step's Lambda with EventBridge rules

In a refund workflow, high-value cases must receive administrator approval, and approval can take several days. What is an appropriate configuration?

• AAn Express workflow + a Wait state to wait several days until approval arrives
• BA Standard workflow + .waitForTaskToken to wait for the approval callback
• CA Standard workflow + .sync to synchronously wait until the approval task completes
• DPut the refund message in an SQS delay queue so it is processed automatically several days later

A mobile app needs to fetch users (DynamoDB), orders (Lambda), and recommendations (OpenSearch) in one go on a single screen, and receive order status changes in real time. What is an appropriate service?

• APut an integration backend Lambda behind API Gateway REST that merges the three sources into the response, and poll periodically for status changes
• BAWS AppSync (multiple resolvers + @aws_subscribe real-time subscriptions)
• CCall 3 separate REST endpoints for users, orders, and recommendations, and receive status changes through client polling
• DCollect the three sources with Kinesis Firehose, load them to S3, and have the client query from there

A Lambda consumes an SQS queue, but the same message is processed in duplicate. The function timeout is 60 seconds. What is the most appropriate action?

• AReduce the visibility timeout to 30 seconds
• BSet the visibility timeout to at least 6 times the function timeout (about 360 seconds)
• CTurn off long polling
• DSwitching to FIFO solves it unconditionally

You want to preserve and analyze messages that SNS repeatedly failed to deliver to an HTTPS endpoint. What is an appropriate method?

• ATurn on message retention on the SNS topic so failed deliveries remain in the topic
• BConfigure an SNS DLQ (an SQS queue) on that subscription with a redrive policy
• CAttach a Lambda DLQ to the subscribed function to preserve failed asynchronous invocation messages
• DPut SQS in front of the HTTPS endpoint and send what exceeds maxReceiveCount to an SQS DLQ

Three consumers must each read the same Kinesis stream with latency of tens of ms, and they must not take throughput from each other. What is the appropriate feature?

• AWith classic shared reads, shorten the GetRecords polling interval so the three consumers read fast enough
• BEnhanced Fan-Out, providing a dedicated 2 MB/s per consumer through HTTP/2 push
• CTriple the shards so each consumer effectively gets dedicated throughput and lower latency
• DSwitch to Firehose so each of the three consumers receives buffered batches