⚠️ Payment service - kubectl logs -f deployment/payment-service -n web-payment⚠️ Notification service - kubectl logs -f deployment/notification-service -n web-notification⚠️ Order service - kubectl logs -f deployment/order-service -n web-order
The Web Store is built on a microservices architecture where each service handles a specific domain of the application:
- Order Service: Manages order creation and processing
- Notification Service: Handles customer notifications
- NATS: Provides reliable event-based communication between services
- API Gateway (Nginx): Routes external requests to appropriate services
Each service is independently deployable, scalable, and resilient, with communication primarily happening through asynchronous events.
Handles the creation and management of customer orders.
Key Features:
- Order creation and retrieval
- Event publishing using NATS JetStream
- MySQL database for persistence
- Fallback and retry logic for communication failures
Processes events from other services and sends appropriate notifications.
Key Features:
- Durable JetStream subscriptions
- Explicit message acknowledgment
- Resilient to service outages
Central messaging system for inter-service communication.
Key Features:
- Persistent message storage
- Guaranteed delivery
- Durable subscriptions
- Monitoring via web interface
Entry point for external access to internal services.
Key Features:
- Request routing
- Load balancing
- Swagger UI access per service
NATS JetStream is used for reliable event publishing and consumption.
order.created— when a new order is placedorder.cancelled— when an order is cancelled
- Message persistence
- Explicit acknowledgment
- Redelivery for failed messages
- Durable subscriptions
REST Endpoints:
| Method | Endpoint | Description |
|---|---|---|
| POST | /api/orders |
Create a new order |
| GET | /api/orders/:id |
Get an order by ID |
| GET | /api/orders/events/status |
Get event publishing stats |
| GET | /health |
Health check |
Swagger UI:
- Local: http://localhost:4001/api-docs
- Gateway: http://localhost:80/docs/orders
Sample Request:
POST /api/orders
Content-Type: application/json{ "product": "Wireless Headphones", "quantity": 2, "email": "customer@example.com" }
REST Endpoints:
| Method | Endpoint | Description |
|---|---|---|
| GET | /api/events/status |
JetStream connection status |
| GET | /api/events/stats |
Message processing statistics |
| GET | /health |
Health check |
Swagger UI:
- Local Development: http://localhost:4002/api-docs
- Gateway Access: http://localhost:80/docs/notifications
Implement Durable Subscriptions with JetStream
Testing the Notification Service Downtime Scenario To test what happens when the notification service goes down and to check if JetStream properly handles missed events, follow these steps: Step 1: Scale Down the Notification Service
kubectl scale deployment notification-service --replicas=0 -n web-notification
Step 2: Create Orders During Notification Service Downtime Step 3: Verify the Events Were Stored in JetStream
kubectl port-forward svc/nats 8222:8222 -n web-nats
You should see the ORDERS stream with stored messages that weren't delivered yet. Step 4: Scale the Notification Service Back Up
kubectl scale deployment notification-service --replicas=1 -n web-notification
kubectl logs -f deployment/notification-service -n web-notification
Implementing Message Acknowledgment Let's add proper message acknowledgment to both services to ensure messages are processed reliably.
- Explicit acknowledgment - Messages are explicitly acked only after successful processing
- Redelivery management - Failed messages are redelivered with exponential backoff
- Message tracking - Both services track messages to prevent duplicates and monitor stuck processing
- Retry mechanism - The order service periodically retries failed event publishing
- Message statistics - Both services provide endpoints to check message processing stats