Full-stack · Coffee franchise platform

eCoffee

A coffee-franchise supply-chain platform spanning online orders, in-store sales, delivery, and inventory.

Visit live site

FocusFranchise operations

Project typeFPT Software mock project · Jun-Aug 2026

Technology

React

NestJS

gRPC

TypeScript

PostgreSQL

Prisma

KafkaJest

DockerGitLab CI/CD

My roleFull-stack contributor · FPT Software mock project

ScopeContributed to the Warehouse, Inventory, Supplier, and Franchise services in an existing 13-service system; work covered NestJS APIs, four Prisma schemas, and related React interfaces.

The challengeOnline orders, counter sales, last-mile delivery, and warehouse transfers involve different roles and inventory pools. The system needs clear role and store boundaries while keeping order and stock changes traceable.

OutcomeConnected service workflows through gRPC and Kafka as part of a three-developer Scrum team.

Inside the product

Choose a screen, then open it for a closer look.

My contribution

What I worked on

Full-stack contributor · Team project

01
Identity & sessions
Contributed to Warehouse, Inventory, Supplier, and Franchise services within an existing 13-service system.
02
Delivery contracts
Designed NestJS APIs and four Prisma schemas, and built related React interfaces.
03
Event reliability
Implemented gRPC service communication and Kafka event workflows; used Jest, Docker, and GitLab CI/CD.

Overview

eCoffee serves customers and the teams behind a coffee franchise in one product. Customers browse menus, place and pay for orders, and use loyalty benefits; staff handle counter sales and fulfillment; managers run store inventory and suppliers; admins oversee policy and chain-wide reporting.

The challenge

Online orders, counter sales, last-mile delivery, and warehouse transfers involve different roles and inventory pools. The system needs clear role and store boundaries while keeping order and stock changes traceable.

Engineering approach

Use gRPC for synchronous service contracts

Why this choice

Delivery assignment and tracking need a direct service response; protobuf contracts keep request and response shapes explicit.

Trade-off

Callers depend on service availability and compatible contracts, so timeouts and version discipline matter.

Pair an outbox with at-least-once Kafka delivery

Why this choice

The order record and outbox event share a local transaction; an outbox/inbox flow tolerates duplicate Kafka delivery without a distributed transaction.

Trade-off

Delivery can repeat, so consumers need deduplication and idempotent effects; the design favors recovery over exactly-once claims.

Keep operational data owned by each service

Why this choice

Order, Delivery, Warehouse, and Inventory own independent records; cross-service references travel as IDs and events, not cross-database foreign keys.

Trade-off

Ownership limits accidental coupling but makes workflows and compensations explicit across service boundaries.

Product capabilities

Online ordering, pickup, delivery & PayOS

Customer accounts, loyalty, 2FA & Cofi assistant

Staff POS, order lifecycle & driver tracking

Inventory, suppliers, purchasing & store transfers

System overview

Documented target architectureeCoffee

Target · partly verified

A public REST edge routes into bounded services. Internal gRPC handles synchronous calls; Kafka carries asynchronous events.

Customer, staff & POS apps

HTTPS · REST / JSON

Kong API Gateway

Routes to service owners

Order · Inventory · Delivery

Asynchronous reliability pattern

Transactional outbox → Kafka → inbox

Architecture direction · partial prototype

Order DB + outbox

poll / publish

Outbox relay

async event

Kafka topics

consume / dedupe

Consumer inbox

Outbox/inbox and cross-service adoption are documented as partial or unverified; this is not an exactly-once claim.

Each service owns a separate logical database and migrations.gRPC for synchronous calls · Kafka for asynchronous events.

This diagram reflects the supplied architecture documents. They describe a target service catalog and mark several cross-service behaviors as partially implemented or unverified.

Evidence & validation

The CV describes this as a training mock project and names the four services and tools used; this page presents team scope without assigning the whole system to one person.

CV mô tả đây là dự án mô phỏng trong chương trình đào tạo, nêu rõ bốn service và công cụ đã dùng; trang này giữ đúng phạm vi làm việc nhóm, không nhận toàn bộ hệ thống là đóng góp cá nhân.

Design considerations

eCoffee is a multi-role system: customer features and store operations depend on the same order and inventory state. Mapping each workflow by actor and scope helps clarify the boundaries between the franchise, its branches, and the warehouse.