A live auction platform must push bid updates to 50,000 browsers in under a second and broadcast each new bid to all watchers while tracking active connections. Polling overloads the backend. Which architecture supports real-time bidirectional messaging for this fan-out requirement?
Select an answer to reveal the explanation.
Short Explanation
Auctions can’t wait for refresh clicks; you need bids to reach every watcher instantly. WebSocket APIs keep two-way connections open, letting your backend push each new bid to thousands of browsers while tracking who is connected.
Full Explanation
API Gateway WebSocket APIs provide persistent, full-duplex channels, so browsers can submit bids upstream and receive broadcasts downstream in milliseconds. Lambda handles connection and message routes, while DynamoDB stores connection IDs so the backend can track active browsers and iterate through them with postToConnection to fan out each bid to 50,000 watchers without polling. An Application Load Balancer with EC2 WebSocket servers can also hold persistent sessions, but it does not provide the same managed scaling: connection state in server memory can require sticky sessions, and custom broadcast loops become fragile at this fan-out. API Gateway HTTP APIs with server-sent events suit one-way tickers, but events flow only from server to client, so they do not provide a native upstream path for placing bids on the same connection. Amazon SNS topics with mobile and email subscriptions can distribute notifications, but they do not provide real-time browser socket delivery or an active-connection registry. Exam caveat: distinguish browser push from backend fan-out; SNS can distribute messages, but it does not replace the WebSocket connection used to deliver updates to connected browsers. Practical check: verify TTL cleanup, handle GoneException for stale connections, and load-test concurrent connection limits and p99 broadcast latency.