Topics and subscriptions in GCP - Time & Space Complexity
When working with topics and subscriptions in cloud messaging, it is important to understand how the time to process messages grows as the number of messages or subscriptions increases.
We want to know how the number of operations changes when we add more messages or subscribers.
Analyze the time complexity of the following operation sequence.
// Create a topic
const topic = pubsub.topic('my-topic');
// Create multiple subscriptions
for (let i = 0; i < n; i++) {
topic.createSubscription(`sub-${i}`);
}
// Publish m messages to the topic
for (let j = 0; j < m; j++) {
topic.publishMessage({ data: Buffer.from(`message ${j}`) });
}
This sequence creates n subscriptions to a topic and publishes m messages to it.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Creating subscriptions and publishing messages.
- How many times: Creating subscriptions happens n times; publishing messages happens m times.
As the number of subscriptions (n) increases, the number of subscription creation calls grows linearly. Similarly, publishing m messages grows linearly with m.
| Input Size (n subscriptions, m messages) | Approx. API Calls/Operations |
|---|---|
| 10, 10 | About 20 calls (10 createSubscription + 10 publish) |
| 100, 100 | About 200 calls |
| 1000, 1000 | About 2000 calls |
Pattern observation: The total operations grow roughly in direct proportion to the sum of subscriptions and messages.
Time Complexity: O(n + m)
This means the time to complete these operations grows linearly with the number of subscriptions plus the number of messages.
[X] Wrong: "Publishing messages to a topic with many subscriptions takes longer for each message because it sends to all subscribers at once."
[OK] Correct: Publishing a message is a single operation; the message fan-out to subscriptions happens asynchronously and does not increase the publish call time.
Understanding how operations scale with the number of subscriptions and messages helps you design efficient messaging systems and answer questions about system behavior under load.
"What if we batch publish messages instead of publishing one by one? How would the time complexity change?"
Practice
topic in Google Cloud Pub/Sub?Solution
Step 1: Understand the role of a topic
A topic is where messages are sent or published by a publisher.Step 2: Differentiate topic from subscription
Subscriptions receive messages from topics, not the other way around.Final Answer:
To send messages to subscribers -> Option DQuick Check:
Topic = message sender [OK]
- Confusing topic as receiver instead of sender
- Thinking topics store messages permanently
- Mixing roles of topic and subscription
Solution
Step 1: Identify correct command syntax
The command to create a subscription usessubscriptions createwith the subscription name and--topicflag for the topic.Step 2: Verify gcloud pubsub subscriptions create my-sub --topic=my-topic matches syntax
gcloud pubsub subscriptions create my-sub --topic=my-topic correctly usesgcloud pubsub subscriptions create my-sub --topic=my-topic.Final Answer:
gcloud pubsub subscriptions create my-sub --topic=my-topic -> Option AQuick Check:
Subscriptions create with --topic flag [OK]
- Using topics create instead of subscriptions create
- Swapping topic and subscription names
- Using --subscription flag instead of --topic
from google.cloud import pubsub_v1
subscriber = pubsub_v1.SubscriberClient()
subscription_path = subscriber.subscription_path('my-project', 'my-sub')
def callback(message):
print(f'Received: {message.data.decode()}')
message.ack()
streaming_pull_future = subscriber.subscribe(subscription_path, callback=callback)
print('Listening for messages...')
Solution
Step 1: Understand code flow
The code subscribes to a topic and sets a callback to print received messages and acknowledge them.Step 2: Identify output behavior
It prints 'Listening for messages...' immediately, then prints 'Received: ...' when a message arrives.Final Answer:
Listening for messages... followed by Received: <message content> -> Option CQuick Check:
Subscribe prints listening then message received [OK]
- Assuming callback runs before print
- Thinking no output until message arrives
- Ignoring message acknowledgment
Solution
Step 1: Check subscription-topic link
If subscription is not linked to the right topic, it won't receive messages.Step 2: Evaluate other options
Topic existence is important but usually creation fails if topic missing; name length or message size usually cause errors, not silent no messages.Final Answer:
The subscription is not attached to the correct topic -> Option AQuick Check:
Subscription-topic mismatch blocks messages [OK]
- Ignoring subscription-topic association
- Assuming message size silently blocks delivery
- Thinking subscription name length causes no messages
Solution
Step 1: Understand message fan-out
One topic can send messages to many subscriptions, allowing multiple services to receive independently.Step 2: Evaluate options
Create one topic and multiple subscriptions, one per service uses one topic with multiple subscriptions, which is the recommended pattern for multiple independent consumers.Final Answer:
Create one topic and multiple subscriptions, one per service -> Option BQuick Check:
One topic, many subscriptions for multiple services [OK]
- Creating multiple topics unnecessarily
- Using one subscription shared by all services
- Linking subscriptions to multiple topics
Ready to prove it?
Pass the test and this pattern moves unknown
