PROFESSIONAL-CLOUD-DEVELOPER · Question #291
You manage a microservice-based ecommerce platform on Google Cloud that sends confirmation emails to a third-party email service provider using a Cloud Function. Your company just launched a…
The correct answer is B. Configure the sender application to publish the outgoing emails in a message to a Pub/Sub topic. The root problem is that HTTP 500 errors cause emails to be permanently lost - if the Cloud Function fails, the calling service has no durable record of the message. Publishing to a Pub/Sub topic decouples the sender from the Cloud Function: Pub/Sub durably stores messages and…
Question
You manage a microservice-based ecommerce platform on Google Cloud that sends confirmation emails to a third-party email service provider using a Cloud Function. Your company just launched a marketing campaign, and some customers are reporting that they have not received order confirmation emails. You discover that the services triggering the Cloud Function are receiving HTTP 500 errors. You need to change the way emails are handled to minimize email loss. What should you do?
Options
- AIncrease the Cloud Function's timeout to nine minutes.
- BConfigure the sender application to publish the outgoing emails in a message to a Pub/Sub topic.
- CConfigure the sender application to write emails to Memorystore and then trigger the Cloud
- DConfigure the sender application to retry the execution of the Cloud Function every one second if
How the community answered
(31 responses)- A3% (1)
- B65% (20)
- C23% (7)
- D10% (3)
Explanation
The root problem is that HTTP 500 errors cause emails to be permanently lost - if the Cloud Function fails, the calling service has no durable record of the message. Publishing to a Pub/Sub topic decouples the sender from the Cloud Function: Pub/Sub durably stores messages and retries delivery until the subscriber (Cloud Function) successfully processes them. This eliminates email loss caused by transient failures. Option A (increasing timeout) does not address the underlying delivery failure. Option C (Memorystore) is in-memory and volatile - data is lost if the instance restarts. Option D (retry every second) can cause thundering-herd problems and still loses messages if the caller itself fails before the retry succeeds.
Topics
Community Discussion
No community discussion yet for this question.