Publish-subscribe architecture in IOT Protocols - Time & Space Complexity
We want to understand how the work done by a publish-subscribe system grows as more devices or messages are involved.
How does the system handle more subscribers or more messages efficiently?
Analyze the time complexity of the following publish-subscribe message dispatch code.
// Pseudocode for message dispatch in publish-subscribe
function publish(topic, message) {
subscribers = getSubscribers(topic);
for each subscriber in subscribers {
sendMessage(subscriber, message);
}
}
This code sends a message to all subscribers of a given topic.
Look for repeated actions that take most time.
- Primary operation: Loop over all subscribers to send messages.
- How many times: Once for each subscriber subscribed to the topic.
As the number of subscribers grows, the number of send operations grows the same way.
| Input Size (subscribers) | Approx. Operations (sendMessage calls) |
|---|---|
| 10 | 10 |
| 100 | 100 |
| 1000 | 1000 |
Pattern observation: The work grows directly with the number of subscribers.
Time Complexity: O(n)
This means the time to send messages grows linearly with the number of subscribers.
[X] Wrong: "Sending one message to a topic always takes the same time, no matter how many subscribers there are."
[OK] Correct: Each subscriber must receive the message, so more subscribers mean more send operations and more time.
Understanding how message dispatch scales helps you design systems that handle many devices smoothly. This skill shows you can think about system growth and efficiency.
What if the system cached messages and sent them in batches? How would that change the time complexity?
Practice
Solution
Step 1: Understand the broker's function
The broker acts as a middleman that receives messages from publishers.Step 2: Identify message forwarding role
The broker forwards these messages to subscribers interested in specific topics.Final Answer:
To receive messages from publishers and forward them to subscribers -> Option AQuick Check:
Broker forwards messages [OK]
- Thinking broker connects devices directly
- Assuming broker stores messages permanently
- Confusing broker with encryption service
Solution
Step 1: Define what a topic is
A topic is a label or category that organizes messages so subscribers receive only relevant ones.Step 2: Eliminate incorrect options
Topics are not connections, security protocols, or devices.Final Answer:
A label used to organize messages for subscribers -> Option AQuick Check:
Topic organizes messages [OK]
- Confusing topics with device connections
- Thinking topics are security features
- Mixing up topics with publishers
home/temperature. Which device will receive the messages?Solution
Step 1: Identify the topic published to
The device publishes tohome/temperature.Step 2: Determine which subscribers get the message
Only devices subscribed tohome/temperaturereceive the messages.Final Answer:
Any device subscribed tohome/temperature-> Option CQuick Check:
Subscribers to topic get messages [OK]
- Assuming all devices get messages
- Thinking publishing device receives its own messages
- Confusing similar topic names
Solution
Step 1: Check subscription correctness
If the subscriber is not subscribed to the right topic, it won't get messages.Step 2: Rule out other causes
Publishers don't send messages directly; encryption issues or wrong roles are less common causes here.Final Answer:
Subscriber is not subscribed to the correct topic -> Option DQuick Check:
Correct topic subscription needed [OK]
- Thinking publisher sends messages directly
- Blaming encryption without evidence
- Confusing subscriber and publisher roles
Solution
Step 1: Use topic hierarchy for targeted messaging
Publishing tofactory/floor1/temperaturetargets only devices subscribed to that specific area.Step 2: Avoid broad topics or direct device addressing
Broad topics or direct IP messaging reduce scalability and flexibility.Final Answer:
Publish temperature alerts to topicfactory/floor1/temperatureand have devices subscribe to it -> Option BQuick Check:
Use specific topics for targeted delivery [OK]
- Using broad topics causing unwanted message delivery
- Trying direct device IP messaging in pub-sub
- Ignoring topic hierarchy benefits
Ready to prove it?
Pass the test and this pattern moves unknown
