Skip to content
AM
Back to Projects
InternalPrivate implementation details removed. CAMI is not expanded. This case study focuses on public-safe engineering patterns.

Dynamic CAMI Backend Service Layer

A zero-to-one backend service layer for dynamic CAMI forms, with HLD/LLD collaboration, database design, and service-layer implementation for flexible form-driven enterprise workflows.

Role: Full-stack Engineer — contributed HLD, LLD, database design, and NestJS/Node service-layer implementation.Duration: 2025
NestJSNode.jsTypeScriptService LayerDatabase Design

Context

Enterprise form workflows often need flexible field definitions, validation, and conditional behavior. Hardcoding every variation creates slow releases and operational risk.

Problem

Form-driven product workflows needed a backend foundation that could evolve without shipping hardcoded frontend changes for every variation.

Ownership

  • Participated in HLD and LLD for dynamic form workflows
  • Contributed to database design for form configuration and runtime reads
  • Helped implement NestJS/Node service-layer logic for flexible form-driven workflows
  • Collaborated across Product, Design, Backend, and Engineering leadership

Architecture

Internal operators and product teams define form schemas → NestJS form service validates and persists configuration → product UI reads runtime form definitions through a service layer. Exact storage engine and internal schema names are intentionally omitted.

flowchart LR
  Stakeholders[Product / Ops] --> Design[HLD / LLD]
  Design --> FormAPI[NestJS Form Service]
  FormAPI --> Validation[Schema Validation]
  Validation --> DB[(Form Config Store)]
  ProductUI[Product UI] --> RuntimeAPI[Runtime Form API]
  RuntimeAPI --> FormAPI
  FormAPI --> ProductUI

Schema Example

export type DynamicField = {
  id: string;
  label: string;
  type: 'text' | 'select' | 'multiSelect' | 'date' | 'checkbox';
  required?: boolean;
  options?: Array<{ label: string; value: string }>;
  visibleWhen?: {
    fieldId: string;
    operator: 'equals' | 'notEquals' | 'includes';
    value: string | boolean;
  };
};

Key Technical Decisions

DecisionWhyTrade-offResult
Schema-driven configurationAvoid repeated hardcoded frontend changesMore upfront schema designEasier runtime updates without code releases
Separated admin write / runtime read pathsDifferent access patterns and security requirementsTwo API surfaces to maintainSafer, more performant product behavior
Cached config read pathConfiguration is read-heavy across user sessionsRequires invalidation/version strategyFaster runtime access with controlled freshness

Implementation

  • Designed DynamicField schema with conditional visibility rules
  • Built admin UI for schema editing, validation preview, and publishing
  • Implemented NestJS service with input validation and error contracts
  • Created database model with versioning and audit trail support
  • Added cache layer with invalidation on configuration publish

Results

  • Shifted selected workflow changes from code releases to controlled configuration updates
  • Improved operational flexibility for internal teams
  • Reduced repetitive frontend changes for configuration-heavy workflows

Reflection

  • The most important decision was separating write and read paths — not the UI design.
  • Schema validation upfront prevented many runtime errors.
  • Next: stronger backward compatibility tooling for schema migrations.
More ProjectsGet in Touch