Pub/Sub

Topics: Logical channels that act as message destinations. Publishers send messages to topics. Publishers: Applications or services responsible for send...

• Explain the core components of Google Cloud Pub/Sub and how they interact. Answer: Google Cloud Pub/Sub is built around three fundamental components

  Topics: Logical channels that act as message destinations. Publishers send messages to topics. Publishers: Applications or services responsible for sending messages to topics. Subscribers: Applications or services that consume messages from subscriptions, which are associated with topics. When a publisher publishes a message to a topic, Pub/Sub delivers that message to all subscriptions attached to the topic. Subscribers then receive messages from their subscriptions, enabling asynchronous, even

• Scenario: Your application needs to process user-uploaded images in real time. How would you design this using Cloud Pub/Sub to ensure scalability and reliability?

  To design a scalable and reliable real time image processing system: Message Publishing: When a user uploads an image, publish a message to a Pub/Sub topic containing metadata such as the image location in Cloud Storage. Subscriber Processing: Create a subscriber service that listens to the topic. Upon receiving a message, it retrieves the image from storage and performs processing tasks such as resizing or analysis. Scalability: Deploy the subscriber service on scalable platforms like Google Ku

• How does message acknowledgment work in Cloud Pub/Sub, and why is it important?

  After a subscriber receives a message, it must send an acknowledgment (ack) to Pub/Sub indicating successful processing. If the message is not acknowledged within the acknowledgment deadline, Pub/Sub assumes failure and redelivers the message. Acknowledgments are critical because they: Enable at least once delivery guarantees Prevent message loss Help manage retries and fault tolerance Proper acknowledgment handling ensures reliable message processing while minimizing duplicates.

• Scenario: You observe that messages are being processed multiple times by your subscriber. What are the possible causes, and how can this be mitigated?

  Messages may be processed multiple times due to: Late Acknowledgments: Processing exceeds the acknowledgment deadline, causing redelivery. Subscriber Failures: Crashes or restarts before acknowledgment result in message redelivery. Mitigation strategies include: Idempotent Processing: Design subscriber logic so repeated processing does not cause incorrect results. Extending Ack Deadlines: Request acknowledgment deadline extensions when processing is lengthy. Robust Error Handling: Implement retr

• Explain the difference between push and pull subscriptions in Cloud Pub/Sub. Answer: Cloud Pub/Sub supports two subscription models

  Pull Subscriptions: Subscribers explicitly request messages from Pub/Sub. This provides greater control over flow management and processing rate. Push Subscriptions: Pub/Sub pushes messages to a configured HTTP endpoint. The endpoint must be able to handle incoming requests reliably. The choice depends on system architecture, latency requirements, and operational control preferences.

• Scenario: Your subscriber service is experiencing high message-processing latency. How can you optimize it using Pub/Sub features?

  To improve subscriber performance: Parallel Processing: Increase the number of subscriber instances to process messages concurrently. Batching: Process messages in batches to reduce per message overhead. Streaming Pull: Use the StreamingPull API to maintain persistent connections and reduce latency. Efficient Acknowledgment: Acknowledge messages promptly after successful processing to avoid redelivery.

• How can you ensure message ordering in Cloud Pub/Sub?

  Message ordering is supported through: Ordering Keys: Publishers assign an ordering key to messages. Messages with the same key are delivered in order. Single Consumer per Key: Ensure that messages with the same ordering key are processed sequentially by one subscriber instance. This feature is useful for workflows requiring strict sequencing, such as financial transactions.

• Scenario: Some messages occasionally fail due to transient errors. How would you implement a retry strategy?

  To handle transient failures: Automatic Redelivery: Pub/Sub automatically retries unacknowledged messages. Exponential Backoff: Implement backoff logic in the subscriber to avoid overwhelming downstream systems. Dead Letter Topics: Route messages to a dead letter topic after a defined number of failures for later analysis.