Go is my preferred language due to its readability, simplicity, and strong performance. It's my first choice for many backend tasks, and I've used it to build microservices, automation scripts, and command-line tools with a focus on clean, efficient design.
All eight Go services expose Prometheus metrics to a live Grafana dashboard.
This platform started as a single ecommerce-service handling products, cart, and orders in one Go binary — a deliberate starting point to demonstrate the full decomposition journey. Over three phases, cart, product, and order responsibilities were extracted into independent services with their own databases, each communicating through well-defined gRPC contracts.
I decomposed the monolithic ecommerce-service into three independent services to demonstrate service extraction patterns, gRPC inter-service communication, and saga-based distributed transactions — skills relevant to teams managing growing microservice architectures. Each service owns its own database, scales independently, and communicates through well-defined contracts.
Seven services communicate via REST (frontend-facing) and gRPC (inter-service). The checkout saga coordinates cart reservation, stock validation, payment processing, and order completion through RabbitMQ command/event queues. Kafka streams analytics events to the analytics-service for real-time aggregation.
Checkout uses a saga orchestrator pattern: the order-service creates a pending order, then asynchronously publishes commands to cart-service via RabbitMQ, validates stock via gRPC to product-service, processes payment via gRPC to payment-service, and clears the cart on success. The client gets an immediate 201 response while the saga runs in the background.
If stock is insufficient at the CheckAvailability step, the saga compensates: order-service publishes release.items to unreserve cart items, issues a payment refund if payment was already created, and marks the order as FAILED. On startup, crash recovery queries incomplete sagas and resumes each from its last known step.
Each service owns its database (productdb, cartdb, orderdb, paymentdb). No shared tables.
Protobuf-defined service contracts with buf toolchain. Type-safe cross-service calls.
RabbitMQ-based saga with compensation flows, DLQ, and crash recovery.
Each service has its own HPA, PDB, and resource limits. Scale what needs scaling.
Benchmark methodology and the full before/after results live on the Database page.