By Rajasekhar Reddy | Senior DevOps Engineer | April 2026

For years, I wanted to build an ecommerce application. I started multiple times and never finished. The scope was always too big, the technology choices paralyzing, the motivation fading after the first few bugs.

Then I decided to stop planning and start shipping. I built a complete ecommerce platform with real payments, deployed it to AWS EKS with full observability, and made it production-ready — all in a few focused sessions.

This is the story of how I built Raj Store, what architectural decisions I made, and why I chose a modular monolith over microservices. Whether you're a developer looking for inspiration, a DevOps engineer curious about full-stack deployment, or a business stakeholder evaluating technology approaches — there's something here for you.

Raj Store — 100 products, real images, search with filters, hover animations

The Problem I Was Solving

Every ecommerce tutorial teaches you the basics — a product list, a cart, maybe a checkout page. But none of them show you what it takes to go from "it works on localhost" to "it's running in production with real payments, real observability, and real deployment pipelines."

I wanted to bridge that gap. Not just build an app, but deploy it the way a real engineering team would.

What I Built

The Application

Raj Store is a full-featured ecommerce platform built with Python (FastAPI) on the backend and server-rendered HTML with Jinja2 + TailwindCSS on the frontend. No React, no separate frontend repo — just clean server-side rendering with HTMX for interactivity.

Core features:

• User authentication with JWT tokens stored in secure HTTP-only cookies

• Product catalog with 100+ real products seeded from DummyJSON

• Full-text search with category filters, price range, and sorting

• Shopping cart with quantity management

• Real payment processing via Stripe Checkout (test mode)

• Complete order lifecycle: Pending → Confirmed → Shipped → Delivered

• Amazon-style order numbers (ORD-20260408-A7B2C9)

• Admin panel with dashboard, order management, and Stripe refunds

• Product reviews and 5-star ratings (purchase-gated — only buyers can review)

• Wishlist for saving products

• International shipping addresses with 26-country dropdown

• Email notifications for registration, order confirmation, and status updates

Product detail page with image, pricing, stock status, Add to Cart, wishlist, and customer reviews

Shopping cart with subtotals, total calculation, and Stripe checkout button

Architecture: Why I Chose a Modular Monolith

This is probably the most important decision I made, and it goes against what most tutorials tell you.

When I started planning, my instinct was to split everything into microservices: auth-service, product-service, cart-service, order-service, payment-service. Seven separate applications, seven databases, seven deployment pipelines.

Then I asked myself: who is this for?

I'm a solo developer building a portfolio project. I don't have a team of 50 engineers who need to deploy independently. I don't have millions of requests per second that require different scaling strategies for different components. I don't have organizational boundaries that mandate service separation.

What I do have is one application that needs to work reliably, be easy to debug, and be impressive to demo.

A modular monolith was the right call. Here's the actual code structure:

app/
├── main.py              # Entry point, router registration
├── config.py            # Environment-based settings (Pydantic)
├── database.py          # SQLAlchemy engine + session
├── dependencies.py      # Auth dependencies
├── otel.py              # OpenTelemetry setup (graceful degradation)
├── models/              # SQLAlchemy ORM models
│   ├── user.py
│   ├── product.py
│   ├── cart.py
│   ├── order.py
│   ├── review.py
│   └── ...
├── schemas/             # Pydantic request/response schemas
├── services/            # Business logic layer
│   ├── product_service.py
│   ├── cart_service.py
│   ├── order_service.py
│   ├── search_service.py   # OpenSearch integration
│   └── email_service.py
└── routers/             # HTTP endpoints
    ├── auth.py
    ├── pages.py         # Server-rendered HTML pages
    ├── product.py
    ├── cart.py
    ├── order.py         # Stripe checkout + payments
    ├── admin.py
    └── ...

Each "module" (auth, products, cart, orders) has its own model, schema, service, and router — but they share one database, one process, and one deployment. This is exactly how Shopify (Rails monolith), GitHub (Rails monolith), and Stack Overflow (.NET monolith) are built.

The key insight: you can always extract a microservice later when you have real traffic patterns showing which module needs independent scaling. Starting with microservices before you have that data is premature optimization at the architectural level.

The Tech Stack

Deployment: Production-Grade EKS

This is where my DevOps background made the difference. The application runs on AWS EKS with a full production deployment pipeline.

Infrastructure (Terraform)

Everything is Infrastructure as Code. One terraform apply creates:

• VPC with private subnets across 3 availability zones

• EKS cluster with managed node groups (5 × t3.small)

• IAM roles with IRSA (IAM Roles for Service Accounts) — no long-lived credentials anywhere

• EBS CSI driver for persistent volume provisioning

• ECR for container image storage

CI/CD Pipeline

The deployment pipeline uses GitHub Actions with OIDC authentication to AWS — no access keys stored anywhere.

Developer pushes code to main
    ↓
GitHub Actions triggers (OIDC → AWS)
    ↓
Docker image built and pushed to ECR
    ↓
ArgoCD detects new image tag in git
    ↓
ArgoCD syncs Helm chart to EKS
    ↓
Rolling update with zero downtime

GitHub Actions build pipeline — OIDC auth, Docker build, ECR push

GitOps with ArgoCD

ArgoCD watches the Helm chart in the git repository. Any change to the chart (new image tag, config change, resource limit adjustment) is automatically applied to the cluster. No manual kubectl apply needed.

ArgoCD application view showing all Kubernetes resources in sync

Secrets Management

Application secrets (database passwords, Stripe API keys, JWT signing keys) are stored in AWS Secrets Manager and synced to Kubernetes via External Secrets Operator. The git repository contains zero secrets — only references to which keys to fetch.

AWS Secrets Manager (raj-store/prod)
    ↓ (ESO syncs every 1 hour)
Kubernetes Secret (raj-store-secrets)
    ↓ (mounted as env vars)
FastAPI Pod

Non-sensitive configuration (service hostnames, ports, feature flags) lives in a Kubernetes ConfigMap managed by the Helm chart.

Observability: Seeing Everything

This is where the project goes from "deployed app" to "production-ready platform." I instrumented the application with three pillars of observability: traces, metrics, and analytics.

Distributed Tracing (OpenTelemetry + Jaeger)

Every HTTP request is automatically traced — from the NGINX ingress through the FastAPI route handler, into every SQL query, and out to external API calls (like Stripe).

Jaeger showing distributed traces — every request broken down into spans with timing

The OpenTelemetry integration is auto-instrumented. I added ~30 lines of setup code, and every FastAPI route, every SQLAlchemy query, and every outbound HTTP call is traced automatically. Health check and readiness probe endpoints are excluded from traces to reduce noise.

When debugging a slow checkout, I can see exactly where time is spent:

POST /orders/checkout-form           2.3s total
├── get_current_user                     2ms
├── get_all_cart_items (SQL)            18ms
├── get_user_addresses (SQL)             8ms
└── stripe.checkout.Session.create   2200ms  ← Stripe API call

Metrics (Prometheus + Grafana)

Prometheus scrapes metrics from the FastAPI application via the /metrics endpoint (provided by prometheus-fastapi-instrumentator). Grafana dashboards show:

• Request rate per endpoint

• Response time percentiles (p50, p95, p99)

• Error rate percentage

• Pod CPU and memory utilization

• HTTP status code distribution

Grafana dashboard — request rate, latency percentiles, error rate, pod resources

Business Analytics (Apache Superset)

Superset connects directly to the PostgreSQL database (via a read-only user for security) and provides SQL-powered dashboards for business metrics:

• Revenue trends over time

• Top-selling products by revenue

• Order status distribution (pending vs confirmed vs shipped vs delivered)

• Customer geography

• Average order value

• Product rating distribution

Superset analytics dashboard — revenue, top products, order status, customer insights

Stripe Integration: Real Payments

The payment flow uses Stripe Checkout — a hosted payment page that handles card validation, 3D Secure, and PCI compliance without any card data touching my server.

Checkout flow:

1. User clicks "Proceed to Checkout" in the cart

2. App creates a Stripe Checkout Session with line items

3. User is redirected to Stripe's hosted payment page

4. After payment, Stripe redirects back with a session ID

5. App verifies payment status with Stripe API

6. Order is created with status "confirmed" and the Stripe payment intent is saved

7. Confirmation email is sent

Refunds are handled through the admin panel. The admin clicks a "Refund" button, which calls the Stripe Refund API with the saved payment intent. The order status updates to "refunded" and the customer receives an email notification. Real money flows back through Stripe — verified in the Stripe Dashboard.

Stripe Checkout page — real payment processing in test mode

Order confirmation page with Amazon-style order number

What I'd Do Differently

1. Start with PostgreSQL from day one. I started with SQLite for local development and migrated to PostgreSQL for production. While SQLAlchemy abstracts most differences, there were small quirks (like ALTER TABLE behavior) that caused unnecessary debugging. Starting with PostgreSQL via Docker Compose would have been smoother.

2. Add Alembic migrations early. I used Base.metadata.create_all() for table creation and manual ALTER TABLE for schema changes. This works for a solo project but doesn't scale. Alembic would have given me versioned, repeatable migrations from the start.

4. Use Stripe webhooks instead of redirect-based verification. The current flow relies on the success redirect to verify payment. If the user's browser crashes after payment but before the redirect, the order isn't created even though the card was charged. Webhooks solve this by having Stripe notify the server directly — independent of the browser.

For DevOps Engineers

If you're a DevOps engineer looking to level up your application development skills, this project covers:

• How authentication actually works in web apps (JWT, cookies, middleware)

• Why database schema design matters (foreign keys, indexes, relationships)

• How payment gateways integrate (Stripe's redirect-based flow)

• What "full-stack observability" means in practice (traces + metrics + analytics)

• How to deploy a real application, not just infrastructure

• When microservices make sense vs when a monolith is the right choice

The biggest insight: once you've built and deployed your own application, you understand developers' problems from the inside. That makes you a dramatically better DevOps engineer.

For Business Stakeholders

If you're evaluating this as a technology approach:

• The modular monolith architecture keeps development velocity high while maintaining code quality

• GitOps deployment means every change is auditable, reversible, and automated

• Full observability means issues are detected and debugged in minutes, not hours

• Scaling is straightforward — increase replica count for the app, upgrade node sizes for the database

• The same codebase serves both the HTML storefront and a REST API (future mobile app ready)

Try It Yourself

• Browse products, search, filter by category

• Create an account and place a test order (use card 4242 4242 4242 4242)

• Check your order history

• Leave a product review

Source code: github.com/rajasekhar-cloud25/ecommerce-api

Rajasekhar Reddy is a Senior DevOps Engineer with 7+ years of experience across AWS, Azure, GCP, and hybrid cloud environments. He holds CKA and Azure Administrator certifications. Connect on rajasekharcloud.com.

In this post I’ll walk you through building a simple AI agent using MCP (Model Context Protocol) and connecting it to Salesforce to fetch real data. The agent will:

• Discover and call tools (Salesforce queries, notifications, updates)

• Execute tool functions when needed

• Return structured, actionable results

🧠 What is MCP?

MCP (Model Context Protocol) is a design approach where the model is given:

• A list of available tools (name, description, input schema)

• Context (conversation + environment data)

• A protocol for asking to call tools and receiving the results

The flow becomes:

1. AI understands the user goal

2. AI chooses a tool and (optionally) constructs structured arguments

3. System executes the tool

4. Tool output is fed back into the model for final response or next step

This helps you keep the agent small, auditable, and safe.

⚙️ Prerequisites

• Node.js (v18+)

• Basic JavaScript / Node knowledge

• OpenAI API key

• Salesforce Developer org (or any org with API access)

• dotenv for env variables

🏗️ Project Setup

mkdir mcp-agent
cd mcp-agent
npm init -y
npm install express openai axios dotenv

Create a .env:

OPENAI_API_KEY=your_openai_key
SF_CLIENT_ID=your_client_id
SF_CLIENT_SECRET=your_client_secret
SF_REFRESH_TOKEN=your_refresh_token
SF_INSTANCE_URL=https://your-instance.salesforce.com
PORT=3000

Notes:

• Use OAuth with a refresh token (offline access) so your service can refresh access tokens without interactive login.

• Store secrets securely (vault/secret manager) in production, not plain .env.

🔗 Connect to Salesforce (recommended approach)

1. In Salesforce: Setup → App Manager → New Connected App

   • Enable OAuth

   • Callback URL: http://localhost:3000/callback (for dev)

   • Scopes: api, refresh_token, offline_access (and others only if needed)

2. Use the refresh token to obtain short-lived access tokens. Example token refresh helper:

// sfAuth.js
import axios from "axios";

export async function getAccessToken() {
  const params = new URLSearchParams();
  params.append("grant_type", "refresh_token");
  params.append("client_id", process.env.SF_CLIENT_ID);
  params.append("client_secret", process.env.SF_CLIENT_SECRET);
  params.append("refresh_token", process.env.SF_REFRESH_TOKEN);

  const res = await axios.post(
    `${process.env.SF_INSTANCE_URL}/services/oauth2/token`,
    params
  );
  return res.data.access_token;
}

(Adjust URL to token endpoint if using a different Salesforce instance domain.)

🔧 Creating Salesforce Tools (MCP)

Tools are plain functions your agent can call. Keep them small, idiomatic, and idempotent where possible.

Example: fetch Accounts.

// tools.js
import axios from "axios";
import { getAccessToken } from "./sfAuth.js";

export async function getAccounts(limit = 10) {
  const accessToken = await getAccessToken();

  const soql = `SELECT Id, Name, Type, Industry, LastModifiedDate FROM Account ORDER BY LastModifiedDate DESC LIMIT ${Number(limit)}`;
  const encoded = encodeURIComponent(soql);
  const url = `\({process.env.SF_INSTANCE_URL}/services/data/v59.0/query/?q=\){encoded}`;

  const res = await axios.get(url, {
    headers: {
      Authorization: `Bearer ${accessToken}`,
      Accept: "application/json",
    },
  });

  // Return minimal fields and count
  return {
    records: res.data.records,
    totalSize: res.data.totalSize,
  };
}

export async function getAccountById(id) {
  const accessToken = await getAccessToken();
  const url = `\({process.env.SF_INSTANCE_URL}/services/data/v59.0/sobjects/Account/\){id}`;
  const res = await axios.get(url, {
    headers: { Authorization: `Bearer ${accessToken}` },
  });
  return res.data;
}

Add other tools similarly: query opportunities, create tasks, update fields, post Chatter messages, etc. Each tool should return structured JSON.

🧩 Registering Tools (tool metadata for the model)

Expose metadata the model can use to decide which tool to call. When you use function-calling (or a simple MCP pattern), the metadata helps the model produce structured calls.

// mcp.js
import { getAccounts, getAccountById } from "./tools.js";

export const tools = [
  {
    name: "getAccounts",
    description: "Fetch recent Salesforce accounts. Args: { limit: number }",
    function: getAccounts,
    // If using function-calling features, include a JSON Schema for args:
    parameters: {
      type: "object",
      properties: {
        limit: { type: "integer", description: "Max number of accounts to fetch" },
      },
      required: [],
    },
  },
  {
    name: "getAccountById",
    description: "Fetch a single Account by Salesforce Id. Args: { id: string }",
    function: getAccountById,
    parameters: {
      type: "object",
      properties: {
        id: { type: "string" },
      },
      required: ["id"],
    },
  },
];

🤖 Building the Agent Orchestrator

Pattern used here (MCP loop):

1. Send user input + tool metadata to the model.

2. If the model returns a function/tool call, run that function locally.

3. Return the tool output to the model as a new message and ask for the final answer.

4. Repeat if the model requests additional tools.

Example agent using the OpenAI function-calling pattern (pseudo-real code for the official Node SDK):

// agent.js
import OpenAI from "openai";
import { tools } from "./mcp.js";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

// small helper to map tool metadata for the model's function parameter
function buildFunctionDefs(tools) {
  return tools.map(t => ({
    name: t.name,
    description: t.description,
    parameters: t.parameters || { type: "object" },
  }));
}

export async function runAgent(userInput) {
  // 1) Ask the model what to do
  const initial = await client.chat.completions.create({
    model: "gpt-4o", // pick a model in your account that supports function-calling
    messages: [
      {
        role: "system",
        content:
          "You are an assistant that can call tools. When you want to call a tool, respond with a function call using JSON arguments matching the declared schema.",
      },
      { role: "user", content: userInput },
    ],
    functions: buildFunctionDefs(tools),
    function_call: "auto",
  });

  const message = initial.choices[0].message;

  // 2) If the model wants to call a function, execute it
  if (message.function_call) {
    const { name, arguments: argsStr } = message.function_call;
    let args = {};
    try {
      args = argsStr ? JSON.parse(argsStr) : {};
    } catch (err) {
      // Bad JSON from model — tell it to reformat
      return {
        error: "Model returned invalid JSON for function call arguments",
        detail: err.message,
      };
    }

    // find the tool function and run it
    const tool = tools.find(t => t.name === name);
    if (!tool) {
      return { error: `Unknown tool: ${name}` };
    }

    let toolOutput;
    try {
      toolOutput = await tool.function(...Object.values(args));
    } catch (err) {
      toolOutput = { error: err.message };
    }

    // 3) Send the tool output back to the model and ask for finalization
    const followUp = await client.chat.completions.create({
      model: "gpt-4o",
      messages: [
        { role: "system", content: "You are an assistant that can call tools." },
        { role: "user", content: userInput },
        message, // original model function call
        {
          role: "function",
          name,
          content: JSON.stringify(toolOutput),
        },
        {
          role: "user",
          content: "Based on the tool output, provide a concise summary and next steps.",
        },
      ],
    });

    const final = followUp.choices[0].message.content;
    return { result: final, toolOutput };
  } else {
    // Model didn't call a tool — just return its text
    return { result: message.content };
  }
}

Notes:

• The above uses the Chat Completions function-calling flow. If you're using the newer Responses API, adapt accordingly to send tool metadata and handle tool calls similarly.

• Validate model-returned JSON and guard against unexpected inputs.

🖥️ Example Express Server

// server.js
import express from "express";
import dotenv from "dotenv";
import { runAgent } from "./agent.js";

dotenv.config();
const app = express();
app.use(express.json());

app.post("/agent", async (req, res) => {
  try {
    const { input } = req.body;
    const out = await runAgent(input);
    res.json(out);
  } catch (err) {
    console.error(err);
    res.status(500).json({ error: err.message });
  }
});

const port = process.env.PORT || 3000;
app.listen(port, () => console.log(`Agent server running on ${port}`));

✅ Practical Patterns & Tips

• Start with a small set of tools (read-only queries first), then expand to mutate data (create/update) with caution.

• Limit scopes in your connected app. Grant only what you need.

• Log function calls with correlation IDs for auditing.

• Sanitize and validate any model-provided arguments before executing tools.

• Add rate limiting and retries when calling external APIs (Salesforce/OpenAI).

• Return structured results (JSON) from tools so the model can reason about data reliably.

• Implement a “dry-run” or “preview” mode where the agent suggests actions but does not execute them unless explicitly approved.

🛡️ Security & Compliance

• Never embed long-lived credentials in code. Use refresh-token + client secret flow and replace secrets using a secure secret store.

• Rate-limit model and API usage, and monitor costs.

• Add RBAC and approvals for destructive operations (e.g., mass-updates).

• Keep sensitive data out of prompts when possible; redact or transform before sending to OpenAI if needed.

🧪 Testing & Iteration

• Start with unit tests for each tool (mock Salesforce responses).

• Test the agent with typical and adversarial prompts to see how it selects tools.

• Add guardrails: deterministic schemas, explicit allowed-values lists, and user confirmations for risky actions.

📈 Next Steps / Ideas

• Add human-in-the-loop approvals for any write operations.

• Expand tools to query related records, compute metrics, or create tasks.

• Build a UI that visualizes the agent’s chosen tool-calls and outputs for auditability.

• Record conversations and actions for compliance and debugging.

Final Thoughts

Using MCP lets you design agents that are flexible yet auditable: the model chooses tools and the system executes them in a controlled environment. Start small, instrument heavily, and gradually add capabilities and safety checks. With a minimal set of tools and a solid orchestration loop, you can automate meaningful Salesforce tasks and free up time for higher-value work.