Cloud-Native Order & Billing Platform for a Multi-Outlet Laundry Chain (Spring Boot, Docker, CI/CD)

FreshFold Cloud is a cloud-native order and billing platform built for FreshFold Laundries, a fictional but realistic eight-outlet laundry chain in Bengaluru with one central washing unit in Peenya. Today each counter writes paper duplicate challans, prices come off laminated rate cards, and the owner learns about a missed delivery only when a customer calls. A single desktop billing application, shared over the shop LAN, is the chain's only digital record — and its single point of failure.

The platform decomposes the business into four independently deployable Spring Boot microservices — customer-service, order-service, billing-service and notification-service — fronted by a Spring Cloud Gateway. Orders (garment lines, status timelines, express flags) live in MongoDB; customers and GST invoices live in MySQL. Every service is packaged as a Docker image and deployed to a Kubernetes (Minikube) cluster with readiness and liveness probes, ConfigMaps and Secrets. A Jenkins pipeline builds, tests and rolls out each service on every push, and Prometheus + Grafana watch request rates, latency percentiles and error budgets.

The stack is industry-standard rather than syllabus-bound, but it exercises exactly what the VTU MCA 2022 curriculum teaches: Advanced Java/J2EE (22MCA341), Cloud Computing (22MCA332), NoSQL Databases (22MCA335), DBMS (22MCA21) and Python (22MCA31) for the load tests. The result is a rigorous, viva-defensible demonstration of distributed-system design, containerisation and delivery automation on a real Indian retail scenario.

FreshFold Laundries runs eight collection counters and one central washing unit in Bengaluru, handling roughly 400–600 orders a day. Every step — intake, washing, pressing, delivery and payment — is recorded on paper challans, and the nightly total is typed into a single desktop billing application shared over the shop LAN. There is no shared, durable record of an order's journey.

The consequences compound daily: garments go missing between a counter and the central unit with no one accountable; express-delivery promises are missed silently; invoices are reconstructed from tally sheets at month-end, producing GST filing errors and billing disputes; the desktop application is a single point of failure with no tested backup; and the owner has no consolidated view of revenue or pending work across outlets.

There is a need for a cloud-native platform that records every order and status change centrally, automates GST invoicing and customer notifications, survives the failure of any single machine or service, scales for weekend peaks, and is improved through an automated delivery pipeline so that a small team can ship changes safely every week.

Abstract

Laundry chains in Indian metros run on paper and trust. At FreshFold Laundries — eight collection counters across Bengaluru and one central washing unit — every garment received is written into a duplicate challan book, totals are keyed into a desktop billing tool at night, and there is no way to answer "where is my shirt?" without three phone calls. FreshFold Cloud replaces this with a containerised, continuously delivered microservices platform that records every order, prints GST invoices automatically and survives the failure of any single machine.

Introduction

A laundry order is small but trace-heavy: a customer, a walk-in or home pickup, a garment list, a service level, wash and press statuses across two locations, delivery and payment. A monolith can store all of this, but counter load (evenings and weekends), month-end billing and notifications have very different scaling and release rhythms. Microservices, each with its own Docker image and Kubernetes deployment, let each concern scale and ship independently — and give the team genuine practice with gateways, service isolation and observability.

Existing system

• Paper duplicate challans at every counter; rates memorised from laminated cards.
• A legacy desktop billing application on one PC, shared over the LAN — a single point of failure.
• Status enquiries by phone; no consolidated revenue view across the eight outlets.
• GST invoices reconstructed monthly from tally sheets, causing filing corrections and disputes.
• Limitations: no audit trail, no tested backups, silent downtime, no data for planning staffing at the central unit.

Proposed system

• A responsive web UI served behind an API gateway; JWT login with roles ADMIN, OUTLET_MANAGER and COUNTER_STAFF.
• Orders captured with garment lines, per-line rates and an express flag; the status timeline (Received → In Wash → Pressed → Ready → Delivered) is appended as immutable timestamped events.
• The billing service computes subtotals, express surcharges and configurable GST slabs, produces per-financial-year invoice numbers and records part or full payments.
• Polyglot persistence: MongoDB documents for orders and status events (the garment list varies per order); normalised MySQL schemas for customers and invoices with foreign-key integrity.
• Notification service consumes order events from RabbitMQ and sends ready-for-pickup and receipt messages by email and SMS.
• A Jenkins pipeline tests, builds and rolls out every service on Minikube; Prometheus and Grafana expose golden signals; Locust load tests verify 200 orders per minute at p95 under 500 ms.

Feasibility study

• Technical: every component is free and open source. Minikube runs on a 16 GB laptop; the manifests are written to be portable to any managed Kubernetes later.
• Economic: ₹0 licence cost. A small cloud node for a permanent demo costs under ₹1,500 per month — less than the chain already spends on challan books and SMS bundles.
• Operational: counter staff already use smartphones; two screens of training are enough. The owner gets his first live, cross-outlet revenue view on day one.

In scope

• One chain: eight outlets, one central washing unit, and a role-based web UI for counter staff, outlet managers and the owner.
• Order lifecycle: intake with garment lines and service level, immutable status timeline (Received → In Wash → Pressed → Ready → Delivered), delivery confirmation with a short code shown to the customer.
• GST invoicing with configurable per-line rates, express surcharge, part and full payment recording, and monthly per-outlet revenue reports exported as CSV.
• Customer notifications (email plus an SMS-gateway stub) when an order is ready and on payment receipt.
• Docker images, Kubernetes manifests, a Jenkins pipeline (build → test → image → deploy), Prometheus/Grafana dashboards and Locust load-test scripts.
• Seed data for all eight outlets, staff accounts and three months of sample orders.

Out of scope (v1)

• A customer-facing mobile app (the web UI is responsive instead).
• Online payment-gateway integration (payments are recorded with a reference number and reconciled manually).
• Route optimisation for pickup vans and RFID garment tagging.
• Migration to a managed cloud provider — the manifests are written to make it straightforward, but the project itself runs on Minikube.

The project follows the incremental SDLC model, cut into two phases to match the VTU MCA 2022 scheme: 22MCAL35 Project Phase-1 (Semester 3, CIE 100) produces the analysis and design, and 22MCA44 Project Phase-2 (Semester 4, 16 credits, CIE 100 + SEE 100) delivers the implementation, deployment and evaluation. Every increment ends with a working, demonstrable slice of the platform, so feedback from the guide is absorbed before the next increment.

Team split (3 members): Member 1 — gateway, customer-service and JWT security; Member 2 — order-service, MongoDB modelling and billing-service; Member 3 — CI/CD pipeline, Kubernetes manifests, observability and load testing. Each member writes the tests for the modules they own, so individual contribution is visible at the viva.

Testing approach: JUnit 5 with Testcontainers (real MongoDB and MySQL containers) for service tests; Postman/Newman collections for API integration; Locust for load; scripted failure drills with recorded observations.

FreshFold Cloud is a microservices architecture with an API gateway, one database per service, and a delivery pipeline that treats the container image as the only artefact that moves between environments.

1. Edge: the browser app (server-rendered Thymeleaf pages plus a thin vanilla-JS layer for counter screens) speaks HTTPS only to the Spring Cloud Gateway, which validates JWTs, checks roles per route and applies rate limits.
2. Services: customer-service, order-service, billing-service and notification-service are built and scaled independently. Services call each other synchronously (REST via OpenFeign) for reads and publish status changes asynchronously to RabbitMQ.
3. Data: order-service owns MongoDB (orders, garment lines, status events); customer-service and billing-service own separate MySQL schemas. No service reads another service's tables — that is what makes this real microservices rather than a distributed monolith.
4. Platform: everything runs as containers on Minikube. ConfigMaps carry per-environment settings, Secrets carry credentials, and readiness/liveness probes let Kubernetes replace unhealthy pods without human action.
5. Delivery & observability: Jenkins builds on every push; Prometheus scrapes Actuator endpoints; Grafana plots the golden signals (traffic, errors, latency).

flowchart LR
  U["Counter staff / managers (browser)"] -->|HTTPS| GW["Spring Cloud Gateway"]
  GW --> CS["customer-service"]
  GW --> OS["order-service"]
  GW --> BS["billing-service"]
  CS --> MY1[("MySQL - customers")]
  OS --> MO[("MongoDB - orders")]
  BS --> MY2[("MySQL - invoices")]
  OS -->|status events| MQ[("RabbitMQ")]
  MQ --> NS["notification-service"]
  NS --> CH["SMTP / SMS gateway"]
  PR["Prometheus"] -->|scrapes metrics| GW

flowchart TD
  DEV["git push"] --> JK["Jenkins"]
  JK --> T["JUnit tests with Testcontainers"]
  T --> IMG["docker build and push"]
  IMG --> REG["Container registry"]
  REG --> DEP["kubectl rolling update"]
  DEP --> K8S["Minikube cluster"]
  K8S --> DASH["Prometheus + Grafana dashboards"]

erDiagram
  CUSTOMER ||--o{ ORDER : places
  OUTLET ||--o{ ORDER : books
  ORDER ||--|{ ORDER_LINE : contains
  ORDER ||--o{ ORDER_EVENT : "tracks status"
  ORDER ||--|| INVOICE : "is billed by"
  CUSTOMER {
    string id PK
    string name
    string phone UK
    string email
  }
  ORDER {
    string id PK
    string customerId FK
    string outletId FK
    string status
    bool express
    datetime placedAt
  }
  ORDER_LINE {
    string id PK
    string orderId FK
    string garmentType
    int quantity
    decimal rate
  }
  INVOICE {
    string id PK
    string orderId FK
    decimal subtotal
    decimal gstAmount
    decimal total
    string paymentStatus
  }

Invoice totals are computed as quantity × rate + express surcharge, plus a configurable GST rate per line classification. Invoice numbers reset per financial year in the format FFL/2026-27/000123, and the sequence lives inside the billing service's own MySQL schema so numbering stays gap-free under concurrency.

• Managed-cloud migration with a costed worksheet — node pools, storage and egress priced monthly for 1,000 orders/day.
• KEDA/HPA autoscaling on queue depth and CPU, compared against fixed replicas with load tests.
• UPI payments with automatic invoice reconciliation and dues reminders.
• Pickup scheduling and route clustering for home-collection orders.
• Demand forecasting of weekly garment volumes per outlet so the central unit can plan staffing.
• Multi-tenant packaging so the platform can be licensed to other laundry franchises.