Amazon Like E-Commerce Microservices Architecture
Large e-commerce platforms cannot use one database transaction across Order, Payment, Inventory, Shipping, and Notification services. Each service owns its own database and communicates through Kafka events.
Complete System Architecture
Customer
|
v
API Gateway
|
+----------------+
| Authentication |
+----------------+
|
v
Order Service
|
Order DB + Outbox
|
v
Kafka Cluster
|
+---------+----------+------------+
| | | |
v v v v
Inventory Payment Shipping Notification
Service Service Service ServiceMicroservices Responsibility
- API Gateway: Single entry point, authentication, routing, rate limiting
- Order Service: Creates and manages order lifecycle
- Inventory Service: Maintains stock and reservation
- Payment Service: Handles payment authorization and capture
- Shipping Service: Creates shipment after successful order
- Notification Service: Sends email, SMS, push notifications
- Customer Service: Manages customer information
Database Ownership
Order Service
|
+-- Order Database
Inventory Service
|
+-- Inventory Database
Payment Service
|
+-- Payment Database
Shipping Service
|
+-- Shipping DatabaseAPI Gateway Flow
Client never directly calls microservices. All requests go through API Gateway.
POST /api/orders
Client
|
v
API Gateway
|
| JWT Validation
| Rate Limit Check
|
v
Order ServiceOrder Creation Flow
Customer clicks Buy Now
|
v
Order Service
|
|
Transaction Starts
|
+----------------+
| Save Order |
| status CREATED |
+----------------+
|
+----------------+
| Save Outbox |
| ORDER_CREATED |
+----------------+
|
CommitOrder Database State
Orders Table
id status
5001 CREATED
Outbox Table
id event published
1 ORDER_CREATED falseTransactional Outbox Purpose
- Order save and event creation happen in same database transaction
- Database success always creates an event record
- Prevents lost events between database and Kafka
- Background publisher sends events asynchronously
Kafka Topic Design
order.created
inventory.reserved
inventory.failed
payment.success
payment.failed
shipment.created
order.cancelled
inventory.release
notification.sendKafka Event Example
{
"eventId":"abc-123",
"eventType":"ORDER_CREATED",
"orderId":5001,
"productId":15,
"quantity":1,
"amount":120000
}Inventory Service Flow
Kafka
|
v
Inventory Service
|
Check Stock
|
Reserve Quantity
|
+----------------+
| Success |
+----------------+
|
inventory.reservedImportant Scenario: Only One Item Left
Two customers try to buy the same last item at exactly the same time.
Product Stock = 1
User A ---> Buy Product
User B ---> Buy Product
Both requests reach Inventory Service togetherWrong Approach
Read Stock
Stock = 1
User A checks
User B checks
Both think stock available
Result:
Stock becomes -1
Correct Inventory Handling
- Database row locking
- Optimistic locking using version column
- Atomic update query
- Reservation table approach
UPDATE inventory
SET available_quantity = available_quantity - 1
WHERE product_id = 15
AND available_quantity > 0;Only one transaction succeeds because only one row can be updated.
Inventory Reservation Pattern
Inventory
Product
---------
id
stock
Reservation
------------
id
orderId
productId
status
AVAILABLE
RESERVED
RELEASEDPayment Flow
order.created
|
v
Payment Service
|
Charge Gateway
|
+--------------+
| Success |
+--------------+
|
payment.successSaga Pattern Flow
Saga manages distributed business transactions using events and compensation instead of rollback.
Order Created
|
v
Inventory Reserved
|
v
Payment Failed
|
v
Compensation Event
|
v
Release Inventory
|
v
Order CancelledIdempotency Handling
Kafka provides at least once delivery. Consumers may receive duplicate messages. Every consumer must safely process duplicates.
Processed_Event Table
id
consumer
status
abc123
InventoryService
DONE- Before processing event check eventId
- If already processed ignore
- Otherwise process and save eventId
Failure Scenarios
- Kafka temporarily unavailable -> Outbox retries later
- Payment timeout -> Retry payment event
- Inventory failure -> Cancel order
- Duplicate Kafka message -> Idempotency check
- Service down -> Consumer resumes from Kafka offset
Retry and Dead Letter Queue
order.created
|
v
Payment Consumer
|
Failure
|
payment.retry
|
After retries fail
|
payment.DLQComplete Successful Flow
Customer
|
v
API Gateway
|
v
Order Service
|
Save Order + Outbox
|
v
Kafka
|
+----------------+
| |
v v
Inventory Payment
Reserved Success
| |
+-------+--------+
|
v
Order Confirmed
|
v
Shipping Created
|
v
Notification SentCore Production Concepts Used
- API Gateway Pattern
- Database per Service Pattern
- Transactional Outbox Pattern
- Event Driven Architecture
- Kafka Messaging
- Saga Pattern
- Idempotent Consumers
- Optimistic Locking
- Inventory Reservation
- Retry Mechanism
- Dead Letter Queue
- Observability and Monitoring
Next Implementation Steps
- Create Spring Boot Order Service
- Create PostgreSQL schema
- Implement Outbox Publisher
- Configure Kafka Producer and Consumer
- Build Inventory Service with locking
- Build Payment Service
- Add API Gateway
- Add Docker Compose
- Add Kubernetes deployment