Redesign audit-event ingestion: multiple auth instances publish events; multiple audit-service instances consume them via Pub/Sub. How should topics and subscriptions be configured to scale and handle high volume?

The correct approach is to create one Pub/Sub topic and one pull subscription. All authentication instances publish to this single topic. All audit service instances subscribe to the same pull subscription. Pub/Sub's pull subscriptions are designed for competing consumers: when multiple subscribers pull from the same subscription, messages are distributed among them, ensuring that each message is processed exactly once by one of the audit service instances. This scales horizontally as you add more audit service instances, as they will automatically share the message load. Incorrect options: "one pull subscription per audit service instance": This would result in each audit service instance receiving a copy of every message, leading to duplicate processing. "one push subscription with a load balancer": While push subscriptions can work, pull subscriptions offer more control and are generally preferred for competing consumers in this pattern. A load balancer adds complexity that Pub/Sub's pull model handles natively. "one Pub/Sub topic per authentication service": This unnecessarily complicates the architecture and message consumption, requiring audit services to subscribe to multiple topics. "one push subscription per topic, pointing to one audit service": This is inefficient and doesn't leverage Pub/Sub's fan-out capabilities effectively for multiple consumers.