LynCafe

LynCafe is a multi-tenant SaaS platform for restaurant and cafe management. One product, four implementations, each built with a different architecture. Every tenant (restaurant) gets its own subdomain, admin panel, POS, kitchen display, online ordering, and QR table ordering from a single deployment.

What LynCafe does

Who	What they get
Restaurant owners	Admin panel: staff, menu, tables, inventory, suppliers, purchase orders, reports, subscriptions
Kitchen staff	Real-time Kitchen Display System (KDS) and order status screens
Waiters and cashiers	POS terminal, table management, split payments, offline-capable POS
Delivery drivers	Delivery queue, assignment, and tracking
Customers	Storefront, online ordering, QR table ordering, loyalty points
Super admins	Tenant management, subscription plans, platform billing, audit logs

Core domains: menu, orders, reservations, inventory with purchase orders, production batches, staff and HR, billing and subscriptions, finance, loyalty, marketing, delivery, messaging, notifications, reporting, and more.

All four implementations share the same inventory model: sellable products carry a stock_mode of unlimited (made on demand in the kitchen), direct (resold purchased goods whose quantity is fed by purchase receipts), or recipe (availability derived from ingredient mappings). A purchased product the kitchen starts making itself simply flips from direct to recipe or unlimited.

Repository map

Directory	Architecture	Best for
lyncafe-mvc/	Modular monolith, Gin plus GORM, server-rendered pages plus React SPA	Single-binary deployment, smallest ops footprint
lyncafe-ddd/	Domain-Driven Design, clean and hexagonal layers, Connect-RPC plus protobuf	Studying or extending DDD, strongest module boundaries
lyncafe-mimo/	Modular monolith core plus focused services, plain gRPC plus NATS JetStream	Event-driven design with a manageable number of deployables
lyncafe-microservice/	25 independent microservices, Connect-RPC, event-driven via NATS	Independent scaling and deployment per service

Each project is self-contained with its own README, migrations, and deployment files. Pick one and ignore the rest, or compare the same feature across all four.

lyncafe-mvc: modular monolith

Single Go binary serving the API, background jobs, and an embedded React frontend (go:embed). Gin handlers, GORM models, repository plus service layers, WebSocket updates for the KDS, IndexedDB-backed offline POS, and subdomain-based multi-tenancy.

• Stack: Go 1.25, Gin, GORM, PostgreSQL, Redis, React plus Vite plus Tailwind
• Layout: cmd/, internal/ (models, repositories, services, handlers, jobs), frontend/, web/, monitoring/, nginx/, postman/
• Infra: docker-compose.yml, docker-compose.dev.yml, Dockerfile, Air hot reload configs
• Start: see lyncafe-mvc/README.md (environment setup, local domains, make targets)

lyncafe-ddd: domain-driven design

Strict DDD with dependencies pointing inward only: domain (pure business logic, zero framework imports) wrapped by application (use cases), adapter (Connect-RPC handlers, PostgreSQL via pgx plus sqlc, Redis, NATS publishers), and infrastructure. Over 20 bounded contexts, protobuf contracts in proto/, three binaries (server, worker, all).

• Stack: Go 1.26, Connect-RPC, PostgreSQL 18, Redis 7, NATS JetStream, React 19 plus TypeScript plus Tailwind 4
• Codegen: make generate (buf for protobuf, sqlc for SQL); generated code is never hand-edited
• Database: versioned migrations in migrations/, make migrate-up, seed via cmd/server seed
• Start: make dev-backend, make dev-frontend, make dev-worker, or make infra-up for Postgres, Redis, and NATS

lyncafe-mimo: modular core plus services

A middle ground between monolith and microservices. core is a modular monolith (identity, tenant, menu, loyalty, inventory, dashboards) with strict hexagonal modules: private aggregates, value objects (Money as int64 minor units, never float), transactional outbox with per-service worker relays, and event-carried state transfer to read projections. Small satellite services own carts and checkout (order), public read models (storefront), chat (messaging), and delivery (notification).

• Stack: Go 1.26, plain gRPC, NATS JetStream, per-service Postgres with read and write pools, Redis leases for leader-elected jobs
• Edge: stateless gateway bridging browser gRPC-Web to backend gRPC; no proto knowledge, pure pipe
• Frontend: frontend/ (Vite plus React SPA) and frontend-public/ (Next.js), clients generated from service protos
• Start: make infra, make db, then go run ./cmd/server plus go run ./cmd/worker per service, or make stack

lyncafe-microservice: 25 independent services

Fully decomposed system where every service is its own Go module with its own database, proto contracts, migrations, and Dockerfile. Connect-RPC APIs with gRPC-Gateway REST transcoding, transactional outbox plus NATS JetStream for cross-service events (for example orders.preparing drives inventory deduction, inventory.po_received drives menu restocking), and a React 19 storefront.

• Stack: Go 1.26, Connect-RPC, PostgreSQL per service, NATS JetStream, React 19
• Services include: gateway, identity, menu, inventory, order, kitchen, payment, finance, delivery, notification, messaging, loyalty, reservation, tenant, and more
• Codegen: make proto (buf) and make sqlc per service; OpenAPI plus Postman collections generated from annotations
• Start: make infra-up, make infra-migrate, make infra-seed (demo credentials in lyncafe-microservice/README.md)

Which one should I run?

• Want the simplest deploy: lyncafe-mvc.
• Want clean architecture to learn from or extend: lyncafe-ddd.
• Want events and services without 25 deployments: lyncafe-mimo.
• Want full service independence: lyncafe-microservice.

Contributing

Issues and pull requests are welcome. Each project follows its own conventions documented in its README: conventional Go formatting, signed descriptive commits, no destructive git operations, and tests for new behavior.

Author

Md. Najib Islam (developernajib@gmail.com)