Project Details

On-premise deployment of Google Microservice Online Boutique

This project demonstrates the local orchestration and deployment of a multi-service architecture of an e-commerce app across 10 decoupled microservices using Docker and Kubernetes (Minikube). It features secure gRPC inter-service communication, proactive resource budgeting to prevent node exhaustion, and automated self-healing configurations. GitHub Repo

🧩 Why This Project Matters

Managing a monolithic app is straightforward but answering the following questions is challenging:

How do 10 different services find each other, communicate and share resources securely?
What happens to the remaining services when one service crashes or runs out of system memory?
How do you test and run a complex, multi-service setup on a single engineer’s machine without crashing the computer?

This project demonstrate how to take a complex enterprise architecture, thus, Google’s 10-service Online Boutique, and host it reliably in a local Kubernetes environment with automated self-healing, strict resource budgeting, and secure inter-service communication.

⚙️ What I Built

I configured and deployed a complete 10-service e-commerce system inside a local Kubernetes cluster using minikube. The setup includes:

A Web Frontend: The entry point for public users to browse and buy.
8 Backing Microservices: Handling everything from product catalogs and payment processing to shipping logic.
An Ephemeral Cache Layer: A localized Redis instance handling real-time shopping cart storage.
Automated Guardrails: Health checks that automatically reboot failing components and prevent memory overload.

Docker ps output and the listening port of Node.js

UI of the user profile application, database, and Jenkins running as isolated containers.

Mongo Express providing a web interface for inspecting application data.

🏗️ How It Works (Workflow)

User accesses the e-commerce application through the frontend. The frontend receives the user’s request and uses Kubernetes service discovery to locate the appropriate backend microservice without relying on fixed IP addresses. The request is then communicated between the relevant microservices using gRPC, allowing services such as product catalog, cart, payment, shipping, and checkout to work together.

When required, the services interact with Redis to temporarily store and retrieve shopping-cart information, while other supporting services handle specific parts of the transaction. Once the required processing is completed, the response is passed back through the frontend and presented to the user.

Throughout this process, Kubernetes manages the services, maintains their network connectivity, monitors their health, and automatically replaces or restarts unhealthy containers to keep the application running reliably.

🌍 Real-Life Scenario

Imagine a growing e-commerce site on Black Friday or festive seasons:

Traffic spikes, causing the checkout service to freeze up.
A misbehaving service hogs all host CPU, dragging down the rest of the application.
Hardcoded server addresses break whenever a container restarts.

With this Kubernetes setup:

Resource Limits: Every microservice has a hard memory and CPU budget, preventing one bad service from crashing the whole server.
Self-Healing: Unhealthy containers are cut off from live traffic and restarted automatically in seconds.
Stable Inter-Networking: Internal routing points dynamically to active containers, ensuring zero disruption during backend updates.

🛠️ Tools Used

Orchestration: Kubernetes (Minikube)
Containerization: Docker
Service Networking: gRPC, CoreDNS
Version Control: Git & GitHub
Operating System: Linux

🚧 Challenges I Solved

Issue 1: Cluster Bottlenecks & Frozen Services

→ Problem: Running 28+ container instances at once caused the host node to run out of memory, leaving services stuck in a pending state.

→ Solution: I profiled the resource usage of each microservice, reduced baseline CPU allocations to a lean minimum, and expanded the host machine’s virtual engine capacity.

Issue 2: Broken Communication Between Backend Services

→ Problem: Checkout services failed to process orders because internal requests were hitting incorrect port pathways on backend dependencies

→ Solution: Standardized the networking manifests, ensuring incoming traffic maps cleanly to internal target ports while remaining completely hidden from the public internet.

🔮 What I’d Improve Next

Helm Integration: Convert raw setup files into reusable Helm charts for rapid, single-command deployments across different servers.
Ingress Routing: Add an NGINX Ingress Controller to manage domain routing and replace direct entry points.
Live Observability: Add a Grafana and Prometheus monitoring stack to track real-time CPU, memory, and application network usage visually.

🧠 What This Shows About Me

I understand how microservices communicate and operate in containerized production environments.
I focus on system stability, resource management, and failure prevention.
I can troubleshoot complex cluster configurations, diagnostic bottlenecks, and networking failures hands-on.