I built a Go-based e-commerce learning project to practice microservices architecture with a strong focus on engineering decisions over feature quantity.
Service landscape
The system is split into five independent services:
- API Gateway
- User Service
- Product Service
- Cart Service
- Order Service
API Gateway responsibilities
- JWT-based authentication
- Authorization and RBAC
- Request routing
- Rate limiting
- Unified handling of cross-cutting concerns
Architecture style
Each service follows Clean Architecture layers (Domain / Use Case / Repository / Delivery) to keep business logic isolated from infrastructure details and improve maintainability over time.
Data and communication
- Database-per-service pattern
- PostgreSQL for User, Product, and Order services
- Redis for Cart service performance
- gRPC + Protocol Buffers for inter-service communication
Reliability and observability
- Circuit breaker for service-to-service calls
- Graceful shutdown to protect in-flight requests
- Distributed tracing with OpenTelemetry
- Structured logging for data-driven debugging
The full system runs with Docker. The biggest takeaway was understanding how early architecture decisions shape scalability and operability as systems grow.