FastAPI Backend Development Bootcamp · Lesson

Inter-service Communication

Implement various patterns for communication between FastAPI microservices, such as HTTP or message queues.

Inter-service Communication is a free FastAPI Backend Development Bootcamp lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the FastAPI Backend Development Bootcamp learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Why Services Talk

In a microservices architecture, your application isn't one big program. Instead, it's many smaller, independent services working together. For these services to achieve a common goal, they need to communicate with each other.

Imagine an e-commerce system: one service handles user accounts, another manages product inventory, and a third processes orders. When a user places an order, the order service needs to talk to the inventory service to check stock and the user service to get payment details.

HTTP: Direct Conversations

The most common way for microservices to communicate is through HTTP requests. This is like one service directly calling another service's API endpoint.

Synchronous: The calling service waits for a response before continuing.
Simple: Easy to understand and implement, especially for request-response patterns.
Familiar: Uses the same HTTP protocol you're already familiar with for web browsing.

FastAPI services naturally expose HTTP endpoints, making this a straightforward method.

Making an HTTP Request

In Python, the requests library is excellent for making HTTP calls. Here's how one FastAPI service might call another to get user data.

Assume Service B exposes a /users/{user_id} endpoint, and Service A calls it:

import requests

def get_user_from_service_b(user_id: int):
    # In a real scenario, 'service_b_url' would be a config variable
    service_b_url = f"http://localhost:8001/users/{user_id}"
    try:
        response = requests.get(service_b_url)
        response.raise_for_status() # Raises HTTPError for bad responses (4xx or 5xx)
        return response.json()
    except requests.exceptions.RequestException as e:
        print(f"Error calling Service B: {e}")
        return None

if __name__ == "__main__":
    print("Simulating a call to Service B for user 1...")
    user_data = get_user_from_service_b(1)
    if user_data:
        print(f"Received user data: {user_data}")
    else:
        print("Failed to get user data.")
    print("\nNote: For this to truly work, a service B needs to be running at http://localhost:8001.")

Handling HTTP Responses

After making an HTTP request, it's crucial to handle the response properly. This includes checking the HTTP status code and parsing the response body.

Status Codes: 200 OK means success, 404 Not Found means the resource wasn't there, 500 Internal Server Error indicates a problem on the server side.
Response Body: Often contains data in JSON format, which you can parse using response.json().
Error Handling: Always wrap your requests in try-except blocks to catch network issues or server errors.

Resilient HTTP: Timeouts & Retries

Network issues or slow services can cause your HTTP calls to hang or fail. Building resilience into your communication is vital.

Timeouts: Set a maximum duration to wait for a response. If the service doesn't respond within this time, the request fails, preventing your service from hanging indefinitely.
Retries: If a request fails due to a transient error (e.g., network glitch, temporary service overload), you can automatically retry the request a few times with a delay. Libraries like tenacity can help implement this easily.

These strategies improve the robustness of your microservices.

Message Queues: Decoupling Services

Sometimes, direct HTTP calls aren't the best fit. For tasks that don't require an immediate response, or when you want to reduce direct dependencies between services, message queues are powerful.

A message queue acts as an intermediary, storing messages until a consumer service is ready to process them. Popular examples include RabbitMQ and Apache Kafka.

Asynchronous: The sender (producer) doesn't wait for the receiver (consumer) to process the message.
Decoupled: Services don't need to know about each other's direct network locations.
Scalable: Easily handle spikes in load by adding more consumers.

The Producer-Consumer Model

Message queues operate on a simple principle:

Producer: A service that creates and sends messages to a queue. It "fires and forgets" the message.
Queue: A temporary storage buffer that holds messages until they are processed.
Consumer: A service that listens to a queue, retrieves messages, and processes them.

This model allows for robust, scalable, and fault-tolerant communication, especially for background tasks or event-driven architectures.

Conceptual Message Producer

While a full, runnable message queue example is complex, here's a conceptual Python function illustrating how a service might "send" a message to a queue. In reality, this would involve a client library like pika (for RabbitMQ) or confluent-kafka.

Notice that the sender doesn't wait for the message to be processed; it just places it in the queue.

import json
import time

# This is a simplified, conceptual representation.
# In a real app, 'queue_client' would be an actual library client.

class MockQueueClient:
    def publish(self, queue_name: str, message: dict):
        print(f"[{time.time():.2f}] PRODUCER: Sending message to '{queue_name}'...")
        print(f"  Message content: {json.dumps(message)}")
        # In a real scenario, this would send to a message broker
        print("  (Message sent to broker, producer continues its work)")

def send_new_order_event(order_details: dict):
    queue_client = MockQueueClient()
    queue_client.publish("order_processing_queue", order_details)
    print("PRODUCER: Order event sent successfully.")

if __name__ == "__main__":
    order_info = {"order_id": "ORD001", "item": "Laptop", "quantity": 1}
    send_new_order_event(order_info)
    print("\nPRODUCER: Service continues other tasks while order processes.")

When to Choose HTTP

HTTP communication is generally preferred for:

Synchronous Requests: When the calling service needs an immediate response to continue its workflow (e.g., getting user profile data, checking inventory before confirming an order).
Request-Response Patterns: Simple queries, data retrieval, or operations where the client expects a direct result.
Tight Coupling is Acceptable: When services are designed to work closely together and direct calls are efficient.
Real-time User Interactions: Often used for front-end to back-end communication, or when an immediate UI update is needed.

Choosing the Right Tool

You've seen two primary ways services communicate. Each has its strengths. Consider the scenario:

A user submits a complex report generation request that might take several minutes to complete. The user doesn't need to wait for it, but wants to be notified when it's done.

Which communication pattern is best suited for the initial request submission?

Recap: Talking Services

Great job! You've explored the fundamental ways microservices communicate.

HTTP: Best for synchronous, request-response interactions where immediate feedback is needed. It's direct and easy to implement using libraries like requests.
Message Queues: Ideal for asynchronous, decoupled communication, handling long-running tasks, and enabling event-driven architectures. They use a producer-consumer model for robust message delivery.

Choosing the right pattern depends on your specific needs for coupling, latency, and reliability. In the next lesson, we'll dive into building an API Gateway!

Frequently asked questions

Is the “Inter-service Communication” lesson free?

Yes — the full text of “Inter-service Communication” is free to read here on the web, and the FastAPI Backend Development Bootcamp course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the FastAPI Backend Development Bootcamp course, upgrade to CoddyKit PRO.

What will I learn in “Inter-service Communication”?

Implement various patterns for communication between FastAPI microservices, such as HTTP or message queues. You practise FastAPI Backend Development Bootcamp with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start FastAPI Backend Development Bootcamp?

No prior experience is required. FastAPI Backend Development Bootcamp on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Inter-service Communication” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this FastAPI Backend Development Bootcamp lesson?

Yes. Every FastAPI Backend Development Bootcamp lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

Designing Microservices Architecture
Inter-service Communication
Implementing an API Gateway with FastAPI
Service Discovery and Health Checks

← Back to FastAPI Backend Development Bootcamp