Examples & Reference Landscapes

Production-grade example repositories demonstrating the Project-Stack-Resource (PSR) model in action.

Official Reference Repositories

Clone and run these complete, battle-tested TDK landscapes locally with a single command:

tdk-example

Minimal PSR demonstration: 1 project, 2 stacks (identity & appointment), and 4 resources using Hono, Vite, and Bun.

Clone on GitHub ENTERPRISE GOVERNANCE DEMO

tdk-user-management

Enterprise identity governance: 3 stacks (admin, portal, compliance), 6 resources, SCIM 2.0 provisioning, OIDC PKCE, and SIEM workers.

Clone on GitHub ENTERPRISE ERP SYSTEM

tdk-erp-system

Complete enterprise ERP: 7 business domains, 100 microservices, finance through analytics, production-grade architecture.

Clone on GitHub Restaurant ops demo

tdk-restaurant-example

Restaurant operations landscape: 3 stacks (guest, kitchen, operations), 6 resources, live reservation flow, kitchen worker, menu API, and floor app.

Clone on GitHub

New official example

A restaurant stack that feels like a live service.

Clone the repo and run reservations, kitchen pacing, menu availability, and the floor view as separate TDK resources.

Clone repo View manifest

Enterprise-scale architecture

100 microservices. 7 business domains. One command.

Experience the full power of TDK PSR model with a complete enterprise ERP system spanning finance, HR, inventory, sales, manufacturing, supply chain, and analytics.

Clone ERP system View architecture

finance 15 services 4010-4024

hr 12 services 4100-4111

inventory 18 services 4200-4217

sales 20 services 4300-4319

manufacturing 15 services 4400-4414

supply_chain 12 services 4500-4511

analytics 8 services 4600-4607

Restaurant Operations Landscape

The newest reference repo shows how a hospitality team can split the host stand, kitchen pass, menu state, and floor control into independently runnable resources.

Enterprise ERP System Landscape

A production-grade demonstration of enterprise-scale microservice architecture with 100 services across 7 business domains, demonstrating the full power of the TDK PSR model for complex organizational needs.

Finance 15 services • GL, AP/AR, budgeting, tax, assets Human Resources 12 services • records, recruitment, performance, benefits Inventory 18 services • management, warehouse, forecasting, tracking Sales 20 services • CRM, orders, pricing, analytics Manufacturing 15 services • planning, quality, maintenance, BOM Supply Chain 12 services • procurement, logistics, planning Analytics 8 services • BI, data warehouse, ML, dashboard

Reservations Guest bookings, waitlist, and table holds. Kitchen pass Tickets, stations, and course-fire timing. Menu state Item availability, modifiers, and 86s. Floor view Manager visibility across tables and service status.

Reservation API manifest

services/guest/reservation-api/service.json

{
  "appName": "reservation-api",
  "domain": "guest",
  "type": "backend",
  "stack": "guest",
  "port": 4100,
  "dependencies": [],
  "healthCheck": {
    "enabled": true,
    "path": "/health"
  }
}

General Ledger API manifest

services/finance/general-ledger-api/service.json

{
  "appName": "general-ledger-api",
  "domain": "finance",
  "type": "backend",
  "stack": "finance",
  "port": 4010,
  "dependencies": [],
  "healthCheck": {
    "enabled": true,
    "path": "/health"
  }
}

Enterprise User Management Landscape

A multi-stack, zero-trust identity system featuring SCIM 2.0 provisioning, OAuth2/OIDC PKCE, and asynchronous background audit stream workers.

1. Admin Directory API (SCIM 2.0)

services/admin/user-admin-api/service.json

{
  "appName": "user-admin-api",
  "domain": "admin",
  "type": "backend",
  "stack": "admin",
  "port": 4010,
  "dependencies": [],
  "healthCheck": {
    "enabled": true,
    "path": "/health"
  }
}

2. OAuth2 / OIDC Self-Service Portal API

services/portal/user-portal-api/service.json

{
  "appName": "user-portal-api",
  "domain": "portal",
  "type": "backend",
  "stack": "portal",
  "port": 4020,
  "dependencies": [],
  "healthCheck": {
    "enabled": true,
    "path": "/health"
  }
}

3. Asynchronous Audit & SIEM Worker

services/compliance/user-audit-worker/service.json

{
  "appName": "user-audit-worker",
  "domain": "compliance",
  "type": "worker",
  "stack": "compliance",
  "port": 4031,
  "dependencies": ["user-audit-api"],
  "healthCheck": {
    "enabled": true,
    "path": "/health"
  }
}

E-commerce platform

A typical setup with 5 services, wired by manifests alone:

1. API gateway

services/api-gateway/service.json

{
  "appName": "api-gateway",
  "appType": "backend",
  "port": 3000,
  "features": ["typescript", "bun"],
  "stack": "ecommerce",
  "internalDependencies": [
    "order-service",
    "inventory-service",
    "user-service"
  ]
}

2. Order service

services/order-service/service.json

{
  "appName": "order-service",
  "appType": "backend",
  "port": 3001,
  "features": ["typescript", "bun", "prisma"],
  "stack": "ecommerce",
  "internalDependencies": ["database"]
}

3. Frontend store

services/frontend-store/service.json

{
  "appName": "frontend-store",
  "appType": "frontend",
  "port": 5173,
  "features": ["typescript", "vite"],
  "backendName": "api-gateway",
  "basePath": "/store"
}

Microservice architecture

project layout

my-project/
├── services/
│   ├── api-gateway/
│   │   └── service.json      # entry point
│   ├── auth-service/
│   │   └── service.json      # authentication
│   ├── user-service/
│   │   └── service.json      # user management
│   ├── order-service/
│   │   └── service.json      # order processing
│   └── frontend/
│       └── service.json      # web UI
├── tdk.yml                   # TDK configuration
└── Tiltfile                  # generated by TDK

Working with multiple stacks

Organize services by stack for selective startup:

Start only the API stack

terminal

tdk up --stack api

Start only specific services

terminal

tdk up api-gateway order-service

Environment configuration

tdk.yml / tdk.production.yml

# development overrides: tdk.yml
env: development
services:
  - name: api-gateway
    port: 3000
    envVars:
      DEBUG: "true"

# production overrides: tdk.production.yml
env: production
services:
  - name: api-gateway
    port: 3000
    envVars:
      DEBUG: "false"

Common patterns

Frontend + backend

two manifests, one system

# frontend service.json
{
  "appName": "web-app",
  "appType": "frontend",
  "port": 5173,
  "features": ["typescript", "vite"],
  "backendName": "api-server",
  "basePath": "/app"
}

# backend service.json
{
  "appName": "api-server",
  "appType": "backend",
  "port": 3000,
  "features": ["typescript", "bun"],
  "envVars": {
    "FRONTEND_URL": "http://localhost:5173"
  }
}

Worker queue

email-worker / service.json

{
  "appName": "email-worker",
  "appType": "worker",
  "features": ["typescript", "bun"],
  "internalDependencies": ["redis"],
  "replicas": 3
}

SaaS starter

Auth, billing and product behind one gateway. A new hire clones the repo, runs tdk up, and has the entire business (login, subscriptions, dashboard) on their laptop in minutes.

services/auth-service/service.json

{
  "appName": "auth-service",
  "appType": "backend",
  "port": 3101,
  "features": ["typescript", "bun", "prisma"],
  "stack": "saas",
  "internalDependencies": ["database", "redis"]
}

services/billing-service/service.json

{
  "appName": "billing-service",
  "appType": "backend",
  "port": 3102,
  "features": ["typescript", "bun", "prisma"],
  "stack": "saas",
  "internalDependencies": ["database", "auth-service"]
}

Realtime collaboration

A shared board with live cursors. The websocket gateway, the event bus and presence storage all boot together with zero separate infra tickets.

services/realtime-gateway/service.json

{
  "appName": "realtime-gateway",
  "appType": "backend",
  "port": 3201,
  "features": ["typescript", "bun"],
  "stack": "realtime",
  "internalDependencies": ["nats", "redis"]
}

Background jobs at scale

Video transcoding farm: a migrator prepares the queue tables, then three worker replicas drain them. Scale replicas per developer machine.

services/transcode-worker/service.json

{
  "appName": "transcode-worker",
  "appType": "worker",
  "features": ["typescript", "bun"],
  "stack": "media",
  "internalDependencies": ["redis", "database"],
  "replicas": 3
}

terminal

# boot only the media stack, nothing else
tdk up --stack media

Brownfield rescue

The most common real-world case: an existing monorepo with 31 directories and zero manifests. The discovery daemon finds every service, synthesizes missing manifests from directory structure, and the team that was blocked for two weeks boots on day one.

terminal

$ tdk up
[discovery] scanned 31 directories · 12 manifests found
[synthesis] 19 manifests synthesized from structure
[generate] 12-17 files × 31 services → 372-527 artifacts written
[health] 31/31 resources healthy

AI-assisted stack

Every boot also regenerates AGENTS.md and the C4 architecture diagram, so AI coding assistants understand the whole system on their first day, just like human team members.

generated stack artifacts

AGENTS.md                   # assistant briefing, always current
docs/architecture.c4        # system diagram from live topology
dependency-manifest.json    # full service graph

Explore Reference Repositories

Check out our official working projects on GitHub: tdk-example (base PSR stack), tdk-user-management (enterprise SCIM 2.0 & OAuth2 PKCE sales demo landscape), tdk-restaurant-example (restaurant operations demo), and tdk-erp-system (enterprise ERP with 100 microservices).