PKahfi Blueprint

Engineering & Design

PKahfi Blueprint

Platform Engineering Standards

Foundation & Infrastructure

Platform Architecture

The blueprint of PKahfi Platform. A modern, distributed SaaS architecture designed for scalability, multi-tenancy, and rapid delivery.

Modular Monolith Strategy
Code modularity with deployment simplicity. Scaling the platform without the complexity of microservices.

We follow the Modular Monolith pattern within our Monorepo. While all applications can be deployed independently, the core business logic is encapsulated into Bounded Contexts and Shared Packages.

Isolation

Strict boundaries between modules using internal packages.

Shared Kernel

Common logic is centralized in the Shared Kernel layer (@repo/shared-*).

Efficiency

Single deployment unit for reduced dev-ops overhead.

Monorepo Structure
Powered by Turborepo and NPM Workspaces for lightning-fast builds and shared code.

apps/

  • • dashboard - Central Management
  • • pkahfi-docs - Platform Documentation
  • • weddingos - Digital Invitation SaaS
  • • design-system - UI Documentation

packages/

  • • shared/ui - Design System Library
  • • shared/config - Tailwind, TS, ESLint
  • • core/domain - Business Entities
  • • bc/billing - Bounded Context: Billing
Data & Multi-tenancy
Secure, scalable multi-tenant isolation using Prisma and Supabase Row Level Security (RLS).
RLS Isolation
Single DB / Shared Schema
Tenant UUID Partitioning

Our architecture uses a Shared Database approach with strong isolation at the database level using Postgres RLS. This ensures that a tenant can never access another tenant's data, even if the application layer is compromised.

Clean Architecture (DDD)
Separation of concerns through Domain, Application, and Infrastructure layers.
Domain

Pure business logic, entities, and value objects.

Application

Use cases, services, and DTOs.

Infrastructure

Frameworks, DB implementation, and external APIs.

Layer Dependency Rules
Strict unidirectional flow to prevent circular dependencies and spaghetti code.

Golden Rule: Unidirectional Flow

Applications
Domain Core
Infrastructure
Application Services
  • Domain is a LeafThe Domain layer must NEVER depend on any other layer or external package.
  • No Circular DepsPackage A depends on B? B cannot depend on A. Period.
  • Shared Kernel ExceptionPackages under @repo/shared-* can be imported by any layer as utilities.
  • Feature IsolationFeature modules in apps should not import from each other directly (use Shared).
Event-Driven Architecture
Decoupling business logic through Domain Events and Asynchronous Processing.

Events enable modules to communicate without being tightly coupled. We distinguish between Domain Events (internal) and Integration Events (external).

In-Process (Sync)

// Aggregate triggers event

this.addDomainEvent(new UserRegistered(id));

// Dispatched during Save()

await DomainEvents.dispatch(entity);

Used for immediate side effects within the same transaction/bounded context.

Asynchronous (External)

Standard Provider
Inngest (Managed/Local)

Used for cross-module communication and background tasks. We prioritize Inngest to eliminate Redis overhead during the bootstrapping phase. BullMQ is reserved as a future scaling path.

Lean Engineering Strategy
Optimizing for zero-cost infrastructure and maximum velocity during development.

During the Heavy Development phase, we minimize fixed infrastructure costs (No self-managed Redis, No heavy K8s). We leverage:

Postgres as Queue

Using Inngest or simple Postgres-based pooling for reliability without Redis.

Edge-First Runtime

Minimizing cold starts and cold server costs using Vercel Edge/Serverless.

Cloud Native Tech Stack
Modern stack optimized for developer experience and performance.
Next.js 16
NextAuth.js
tRPC / GraphQL
Prisma ORM