Stallora | Flutter Multi-Vendor E-Commerce Platform with Spring Boot Microservices

Stallora is a working multi-vendor marketplace, and a production-shaped Spring Boot microservices reference implementation. Several independent shops sell through one storefront; a basket can hold items from all of them; at checkout the order splits into one delivery per shop; each shop fulfills its own slice and is settled separately with commission taken. You get the whole thing — six services, a server-rendered storefront, two web consoles and a Flutter app for iOS and Android — as source.

Before you buy: this is six JVMs, Kafka and PostgreSQL. It requires a VPS with at least 6 GB of RAM (8 GB recommended) and Docker. Measured peak on a cold start is 3.35 GB across all thirteen containers. It will not run on shared hosting or cPanel, which cannot run Docker or a JVM at all. Payments are deliberately mocked — one interface to implement, documented step by step.

One checkout, one delivery per shop

This is the signature interaction. A basket can hold items from any number of shops. At checkout the order splits into one sub-order per shop — each with its own subtotal, its own fulfillment status and its own settlement. Paying moves all of them at once. Stock is reserved synchronously, so overselling is impossible, and refunds are per shop inside that shop’s return window.

What makes it different from a shop template

• Real service boundaries. auth, catalog, inventory, order and settlement are separate Spring Boot services behind a Spring Cloud Gateway, each with its own PostgreSQL database. No service reads another’s tables.
• Cross-shop consistency done properly. Stock is reserved synchronously with a conditional update, so overselling is impossible; cancellation and timeout compensate through a Saga over a transactional outbox on Kafka — at-least-once, with idempotent consumers. No distributed transaction coordinator.
• Money that survives an argument. Commission resolves most-specific-first (shop, then category, then default) and is frozen onto the bill when it is created. Payouts are two-step: a seller’s request locks the bills, an admin approves. Refunded sub-orders are excluded before billing rather than clawed back. Double-layer reconciliation parks any drift for a human instead of losing it.
• Self-service seller onboarding. A buyer applies from the storefront, an admin approves, and the shop is created and bound to that account in one step.
• One command proves it. deploy/verify-m4.sh builds the jars, cold starts all thirteen containers and walks the entire product path with 32 assertions.

Six services, one gateway, one database each

Every client — the Flutter app, the storefront and both consoles — goes through one Spring Cloud Gateway that validates the JWT, rate limits and denies internal routes at the edge. Behind it, six services each own their own PostgreSQL database; no service reaches into another’s tables. Consistency is events plus compensation over a transactional outbox on Kafka, not a distributed transaction coordinator. One Jaeger trace crosses the gateway, the services and the queue.