Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
An e-commerce company hosts an order submission system on Google Cloud. During marketing flash sales, order submission traffic increases tenfold.
Currently, the frontend microservice synchronously calls an external legacy third-party inventory and payment verification system for each submitted order. The legacy system has strict throughput limitations, does not scale elastically, and responds with high latency under load. Consequently, during traffic spikes, frontend connection pools become exhausted, requests time out, and customer orders fail.
The architecture must meet the following requirements:
Which integration architecture should you implement?
Expose the order API via Apigee for traffic management, publish order events directly to Cloud Pub/Sub to acknowledge requests immediately, and consume messages asynchronously using backend workers throttled to the legacy system's capacity.
Enable archive deployment in an Apigee environment to package and execute local emulator instances of the legacy third-party service during peak traffic loads.
Configure an Apigee API proxy with response caching enabled for all order submission requests, keeping the synchronous communication path between the frontend microservice and the legacy backend.
Implement adaptive throttling on the frontend instances to drop excess incoming synchronous calls before they hit the external legacy service.
Expose the order API via Apigee for traffic management, publish order events directly to Cloud Pub/Sub to acknowledge requests immediately, and consume messages asynchronously using backend workers throttled to the legacy system's capacity.
This architecture combines Apigee API Management with Cloud Pub/Sub asynchronous messaging to decouple frontend intake from downstream processing. Apigee acts as the API gateway providing entry governance, security, and traffic shaping, while Cloud Pub/Sub serves as a distributed, highly scalable buffer that temporarily persists incoming order messages until backend consumers are ready to process them.
Synchronous calls to non-scaling backends inevitably lead to connection starvation and elevated error rates during peak traffic. Introducing asynchronous messaging breaks the temporal coupling between the client request and the third-party execution, fulfilling both customer responsiveness and backend protection.
Enable archive deployment in an Apigee environment to package and execute local emulator instances of the legacy third-party service during peak traffic loads.
Configure an Apigee API proxy with response caching enabled for all order submission requests, keeping the synchronous communication path between the frontend microservice and the legacy backend.
Implement adaptive throttling on the frontend instances to drop excess incoming synchronous calls before they hit the external legacy service.