DVA-C02 DynamoDB Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use an SQS FIFO queue to store connection IDs and have a Lambda function poll the queue to broadcast.

  Why it's wrong here

  Using an SQS FIFO queue to store connection IDs is unsuitable for broadcasting in a real-time chat application. SQS FIFO queues are designed for strict message ordering and exactly-once processing of individual messages, not for maintaining a live, queryable list of broadcast targets. A Lambda function polling the queue would process each connection ID sequentially, introducing significant latency and complexity, as the queue's design does not facilitate retrieving all active connections simultaneously for a broadcast operation.

• ✓

  Store connection IDs in a DynamoDB table. Use a Lambda function to query all connection IDs and send messages using the API Gateway Management API.

  Why this is correct

  Storing connection IDs in a DynamoDB table is the robust and scalable solution for managing WebSocket connections with API Gateway. DynamoDB provides a highly available, low-latency, and persistent store for these IDs. When a message needs to be broadcast, a Lambda function can efficiently query the DynamoDB table to retrieve all active connection IDs. It then uses the API Gateway Management API's `PostToConnection` action to send the message to each client, ensuring reliable and scalable real-time communication.

• ✗

  Maintain an in-memory list of connection IDs in a global variable of a single Lambda function.

  Why it's wrong here

  Maintaining an in-memory list of connection IDs in a global variable of a single Lambda function is fundamentally flawed for a scalable real-time application. AWS Lambda functions are stateless and ephemeral; their execution environments are frequently recycled or new instances are provisioned for concurrent requests. Any data stored in-memory is lost between invocations and not shared across multiple function instances, leading to an incomplete and inconsistent list of active connections and preventing reliable message broadcasting to all users.

• ✗

  Use Amazon ElastiCache Redis to store connection IDs and use Redis Pub/Sub for broadcasting.

  Why it's wrong here

  ElastiCache Redis with Pub/Sub is unsuitable because it broadcasts messages *internally* to subscribed backend services, not directly to external WebSocket clients managed by API Gateway. Lambda functions would still need to retrieve connection IDs and individually invoke API Gateway's `PostToConnection` API for each client. This option is tempting as Redis Pub/Sub is a highly effective, low-latency mechanism for inter-service communication or distributing events *between different backend application instances*.