Implementing RPC client and server in RabbitMQ - Time & Space Complexity
When using RabbitMQ for RPC, we want to know how the time to process requests grows as more requests come in.
We ask: How does the system handle more calls and how does that affect response time?
Analyze the time complexity of the following RabbitMQ RPC server code snippet.
channel.queue_declare(queue='rpc_queue')
def on_request(ch, method, props, body):
n = int(body)
response = fib(n) # Calculate Fibonacci number
ch.basic_publish(exchange='', routing_key=props.reply_to,
properties=pika.BasicProperties(correlation_id=props.correlation_id),
body=str(response))
ch.basic_ack(delivery_tag=method.delivery_tag)
channel.basic_consume(queue='rpc_queue', on_message_callback=on_request, auto_ack=False)
channel.start_consuming()
This code listens for RPC requests, computes a Fibonacci number, and sends back the result.
Look at what repeats when a request arrives.
- Primary operation: The Fibonacci calculation inside
on_request. - How many times: Once per RPC request received.
The time to respond depends on the Fibonacci number requested.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 steps |
| 20 | About 20 steps |
| 30 | About 30 steps |
Pattern observation: The time grows roughly in a straight line as n increases, because each request does a calculation proportional to n.
Time Complexity: O(n)
This means the time to handle each request grows linearly with the size of the input number n.
[X] Wrong: "The RPC server handles all requests instantly no matter the input size."
[OK] Correct: Each request runs a calculation that takes longer for bigger inputs, so response time grows with input size.
Understanding how request processing time grows helps you design better services and explain system behavior clearly in interviews.
What if we changed the Fibonacci calculation to a constant-time lookup? How would the time complexity change?