Description
Stallora | Flutter Multi-Vendor E-Commerce Platform with Spring Boot Microservices
Stallora | Flutter Multi-Vendor E-Commerce Platform with Spring Boot Microservices 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 fulfils 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.
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.
What you get
- Flutter app (Dart) — one codebase for iOS and Android, no web view. Riverpod state, persisted session and cart, search, infinite scroll, per-shop order tracking, refund
requests. Plus a demo mode: one build flag and the app runs the entire buyer journey with no backend at all — which is also the live preview above. - Six Spring Boot services (Java 21) — gateway, auth (RS256 + JWKS), catalog (PostgreSQL full-text search, image uploads), inventory, order, settlement. Flyway migrations,
springdoc, Jaeger tracing across every hop including the queue. - Next.js 15 storefront — server-rendered product and shop pages, sitemap and robots.txt, search and filters, buyer sign-up, cart and checkout.
- Two Refine consoles — an admin console for the platform (applications, catalogue, orders, commission, bills, payouts) and a vendor portal where a seller runs their own
shop and never sees anyone else’s rows. - Deployment — docker-compose for all thirteen containers, health checks, and a 16-section buyer handbook covering VPS setup, TLS, secrets, backups, database work without the
command line, and swapping the mock payment gateway for a real one.
