Reading Microservices Architecture Descriptions

The API Gateway is the single entry point — routing, not business logic:

The passage states: "The API Gateway is the single entry point for all client requests… The Gateway never performs business logic — it routes or rejects."

What the Gateway does do:

• TLS termination → decrypts HTTPS traffic once, so internal services don't have to
• Routing → forwards each request to the correct downstream service
• Auth token validation → rejects unauthenticated requests before they reach any service
• Rate limiting → protects downstream services from traffic floods

Why "no business logic" matters:
If the Gateway made business decisions, every business change would require touching a central shared component — breaking the independence of microservices. The Gateway's job is purely operational.

Architecture vocabulary:

• single entry point → all traffic passes through one place (also called a "front door")
• TLS termination → ending the encrypted tunnel at the gateway, forwarding plain HTTP inside the private network
• rate limiting → rejecting requests above a threshold to prevent abuse or overload

Asynchronous via the message queue — the Order Service does not wait for payment:

The passage is explicit: "Publishes an order.created event to the message queue. Returns the order ID to the caller — it does NOT wait for payment." And on the Payment Service: "Subscribes to order.created events from the message queue."

Synchronous vs. asynchronous communication:

• Synchronous → Service A calls Service B and blocks until B responds. If B is slow, A is slow. If B crashes, A gets an error.
• Asynchronous → Service A publishes an event and continues. Service B processes the event when it's ready. Services are decoupled in time.

Why async here?
Payment processing can take 200–2000ms (external Stripe API call). If the Order Service waited synchronously, every order would be blocked for that duration. With async: the order is accepted instantly, and payment happens in the background.

Evidence the passage gives:
The Order Service "does NOT wait for payment" — this is the clearest signal of asynchronous design. The Payment Service also "never calls the Order Service directly" — no reverse synchronous call exists.

The queue decouples services and provides durability — events survive outages:

The passage says: "Services publish events and subscribe to topics without knowing who else is listening. If a downstream service is temporarily unavailable, events are held in the queue and delivered when the service recovers."

Two distinct problems the queue solves:

1. Decoupling (who is listening?):
The Order Service publishes order.created. It doesn't know whether Payment Service, Analytics Service, or a Notification Service is consuming it — and doesn't need to. If a new consumer is added, the Order Service code changes: zero.

2. Durability (what if a service is down?):
If the Payment Service is restarting during a deployment, the order.created event waits in the queue. When Payment Service comes back, it processes the backlog. Without a queue, the Order Service would get a connection error and either retry (complex) or lose the event (data loss).

Queue vocabulary:

• publish → put a message onto the queue
• subscribe / consume → read messages from the queue
• topic → a named channel (e.g., "order.created")
• backlog → unprocessed messages waiting in the queue

Eventually consistent because async queue updates create a temporary lag:

The passage explains: "Stock counts are updated asynchronously via inventory.reserved events after payment. Because stock updates travel through the queue, a brief window exists where the database may not yet reflect the latest reservations — this is called eventual consistency."

What "eventual consistency" means in practice:

• At time T=0: Payment succeeds, inventory.reserved event published to queue
• At time T=0 to T=50ms: The event is in the queue but not yet processed
• During this window: Another request checking stock would see the OLD (pre-reservation) count
• At time T=50ms: Inventory Service consumes the event, stock count updated
• After T=50ms: All reads see the correct (post-reservation) count

Contrast with strong consistency:
If the Inventory Service were updated synchronously before returning the order confirmation, stock would always be accurate — but the order confirmation would be slower and the Order Service would be tightly coupled to Inventory.

Why teams accept eventual consistency:
For inventory, a 50ms lag is usually acceptable. The system is "eventually" correct — it just takes a moment. This trade-off enables higher throughput and better resilience.

A single point of failure: one component whose failure brings down the whole system:

The passage states: "The queue is the only component on which every other service depends — making it a potential single point of failure if not properly replicated."

Why is this a risk?
In a microservices architecture, the goal is resilience through isolation: one service failing should not cascade to others. But the message queue breaks this property — if the queue is unavailable:

• Order Service can't publish order.created → new orders fail
• Payment Service can't receive events → no payments processed
• Inventory Service can't receive reservations → stock counts stale

The queue connects everything, so its failure is systemic.

How teams mitigate this:
The passage hints at the solution: "if not properly replicated." Production message queues (RabbitMQ, Kafka, SQS) run as clusters across multiple nodes/availability zones. If one node fails, another takes over — eliminating the single point of failure.

Architecture vocabulary:

• single point of failure (SPOF) → a component whose failure causes the entire system to fail
• replication → running multiple copies of a component so failure of one doesn't stop the system
• high availability (HA) → designing systems to remain operational despite component failures