--- title: "B2B Software & ERP Glossary of Terms" description: "Define and learn key B2B software and ERP terminology, from custom development architectures to SOC2 and HIPAA compliance frameworks." canonical: https://erpstack.io/glossary markdown_url: https://erpstack.io/glossary.md publisher: ERPStack --- # B2B Software & ERP Glossary of Terms > **In short:** a working reference of 68 terms from custom ERP, CRM and B2B software > engineering, grouped into 6 categories and connected by 408 > cross-references. Every entry carries an exact definition, a card of concrete figures and cited > standards, how the concept behaves in production, ERPStack's own implementation position, and > 4 questions answered in full — 272 across the set. ## ERP & Business Systems (11 terms) ### Resource Planning & ERP Resource Planning & ERP refers to a centralized software suite used by organizations to manage and integrate core business processes—including finance, supply chain, manufacturing, operations, reporting, and human resources—within a unified database system to ensure data integrity and real-time operational visibility. - **URL:** https://erpstack.io/glossary/erp - **Markdown:** https://erpstack.io/glossary/erp.md - **Scope:** 1 shared schema spanning 5 core domains: finance, inventory, procurement, manufacturing and HR - **Reference stack:** Next.js 16, React 19, Drizzle ORM 0.45, PostgreSQL 18 (default port 5432) - **Integration surface:** REST and GraphQL endpoints plus signed webhooks; Apache Kafka for high-volume event ingestion - **Commercial model:** 100% source-code ownership, 0 per-seat licence fees, deployed to your own AWS or Vercel account - **Built with:** Next.js 16, React 19, TypeScript 5.9, Drizzle ORM 0.45 and PostgreSQL 18 on AWS or Vercel - **Numbers that matter:** 1 transaction spanning stock, ledger and dispatch; 0 nightly reconciliation batches; 5 modules on 1 PostgreSQL 18 schema; 2 API styles, REST and GraphQL - **Packaged alternatives:** SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365, Odoo, Epicor ERP, Sage X3 - **Commonly paired with:** A CRM, a Headless CMS, Apache Kafka ingestion and Sentry error reporting ### Customer Relationship Management (CRM) Customer Relationship Management (CRM) is a software platform that centralizes, manages, and analyzes all interactions and data associated with current, past, and potential customers across sales, marketing, and support channels to optimize client retention and drive revenue growth. - **URL:** https://erpstack.io/glossary/crm - **Markdown:** https://erpstack.io/glossary/crm.md - **Record spine:** 4 linked entities: account, contact, opportunity and activity, keyed to 1 customer identity - **Reference stack:** PostgreSQL 18 with Drizzle ORM 0.45, Next.js 16 server actions, Zod 4 input validation - **Sync pattern:** Idempotent webhooks returning 200 on replay; 409 on conflicting versions rather than silent overwrite - **Access model:** Role-Based Access Control plus Row-Level Security so 1 query cannot leak another team's pipeline - **Built with:** Next.js 16 server actions, Drizzle ORM 0.45 on PostgreSQL 18, Zod 4 validation, Sentry for errors - **Numbers that matter:** 1 customer identity across CRM and ERP; GDPR allows 1 month plus 2 to answer a subject request; 200 on replay, 409 on a version conflict - **Packaged alternatives:** Salesforce, HubSpot, Microsoft Dynamics 365, Zoho Creator, Monday.com - **Commonly paired with:** The ERP ledger, SSO, RBAC and a GDPR subject-request path ### Headless ERP Headless ERP is an architectural pattern that completely decouples the backend database schema, business logic, and transaction processing from the frontend user interface, communicating exclusively via structured API contracts (REST, GraphQL, or RPC). - **URL:** https://erpstack.io/glossary/headless-erp - **Markdown:** https://erpstack.io/glossary/headless-erp.md - **Contract:** 1 backend, N clients: web, mobile and partner integrations over REST, GraphQL or tRPC - **Reference stack:** Drizzle ORM 0.45 and PostgreSQL 18 behind the API; Next.js 16 and React 19 in front of it - **Versioning:** Additive schema changes plus 2 supported API versions during a migration window - **Why it matters:** A UI change ships without touching 1 line of transactional logic - **Built with:** TypeScript 5.9 contracts over Drizzle ORM 0.45 and PostgreSQL 18; React 19 clients on Next.js 16 - **Numbers that matter:** 1 API surface, N clients; 2 supported versions during a migration; 0 UI changes touching the schema; 1 network hop, measured in milliseconds - **Contrast with:** Coupled suites such as SAP S/4HANA, Oracle NetSuite and Epicor ERP - **Commonly paired with:** REST, GraphQL or tRPC clients, SSO, and a Headless CMS for content ### Custom Software Development Custom software development is the process of designing, building, deploying, and maintaining software applications tailored to the specific workflows, business processes, and compliance requirements of a single organization. - **URL:** https://erpstack.io/glossary/custom-dev - **Markdown:** https://erpstack.io/glossary/custom-dev.md - **Deliverable:** 1 repository you own outright, with 0 runtime licence fees attached to the code - **Reference stack:** TypeScript 5.9, Next.js 16, React 19, Drizzle ORM 0.45, PostgreSQL 18 - **Quality gates:** Vitest 4 unit tests and Playwright 1.59 end-to-end runs on every pull request - **Deployment:** Infrastructure as Code into your own AWS or Vercel account, not a vendor tenancy - **Built with:** TypeScript 5.9, Next.js 16, React 19, Tailwind CSS 4, Drizzle ORM 0.45, PostgreSQL 18 - **Numbers that matter:** Roughly 80% bought and 20% built; 1 repository you own; 0 runtime licence fees; 2 test layers, Vitest 4 and Playwright 1.59 - **Compare with:** Configuring Odoo, Zoho Creator, Monday.com or Microsoft Dynamics 365 instead of building - **Toolchain:** Vitest, Playwright, Storybook, Semgrep SAST, OWASP ZAP and GitHub Actions ### B2B Software Custom software is organization-level software designed to coordinate operations, manage transactions, process large volumes of data, and generate business-wide reports for large corporations or institutions. - **URL:** https://erpstack.io/glossary/b2b-software - **Markdown:** https://erpstack.io/glossary/b2b-software.md - **Buying unit:** 1 purchase decision, many stakeholders: end users, IT, security review and finance - **Table stakes:** SSO, Role-Based Access Control, audit logs and an export path — all 4 asked for in security review - **Reference stack:** Next.js 16 and PostgreSQL 18 with multi-tenant isolation from day 1 - **Failure mode:** Consumer-grade auth: 1 shared login per company, 0 per-user attribution - **Built with:** Next.js 16, React 19, PostgreSQL 18 with RBAC and SSO, deployed to AWS or Vercel via Terraform - **Numbers that matter:** 4 security-review essentials — SSO, RBAC, audit logs, data export — expected before renewal 1; 1 codebase, 0 per-customer forks - **Compare with:** Salesforce, Monday.com, Zoho Creator and other seat-priced SaaS platforms - **Commonly paired with:** SSO, RBAC, SOC 2 evidence, an ERP integration and a Sentry error feed ### Bill of Materials (BOM) Management A Bill of Materials (BOM) is a comprehensive list of raw materials, assemblies, sub-assemblies, parts, and the quantities of each needed to manufacture an end product. - **URL:** https://erpstack.io/glossary/bom - **Markdown:** https://erpstack.io/glossary/bom.md - **Structure:** A directed acyclic graph, not a list: 1 parent part can expand through 5 or more nested levels - **Core operation:** Explosion — walking the tree to turn 1 finished unit into total component demand - **Storage:** PostgreSQL 18 recursive CTEs over a parent/child table, versioned by effective date - **Change control:** Every revision retained; 0 in-place edits, so a build from 2 years ago still reproduces - **Built with:** PostgreSQL 18 recursive CTEs through Drizzle ORM 0.45, surfaced by Next.js 16 and React 19, revisions retained immutably, procurement and costing in the same AWS-hosted ERP - **Numbers that matter:** 5 or more nesting levels per assembly; 1 new row per revision; 0 destructive edits; 3 quantities multiply at every level of the tree - **Where it lives:** Inside the ERP, not a spreadsheet — SAP S/4HANA, Oracle NetSuite and Epicor ERP all model it - **Commonly paired with:** An Immutable Audit Trail in PostgreSQL 18, AS9100 Aerospace Standard traceability, Drizzle ORM 0.45 recursive queries, Next.js 16 and React 19 screens, RBAC approvals, and procurement inside the same ERP ### Sabre GDS Travel Integration Sabre is a global distribution system (GDS) travel technology platform that connects travel service providers with travel agencies and corporate booking engines globally via real-time APIs. - **URL:** https://erpstack.io/glossary/sabre-gds - **Markdown:** https://erpstack.io/glossary/sabre-gds.md - **Domain:** 1 distribution layer connecting 3 supplier types — airlines, hotels and car hire — to agency systems - **Integration style:** Server-to-server API calls on Next.js 16 routes; 0 credentials ever reach the browser - **Resilience:** Idempotent booking requests with exponential backoff; a replayed call returns 1 reservation, not 2 - **Caching:** Availability cached at the edge for seconds; the fare revalidated 100% of the time before payment - **Built with:** Next.js 16 server routes calling the GDS, secrets held in AWS, Redis for short-lived availability, orders written to PostgreSQL 18 via Drizzle ORM 0.45, errors captured in Sentry - **Numbers that matter:** 1 idempotency key per booking; 2 reservations is the failure it prevents; 0 credentials client-side; fares revalidated 100% of the time before payment - **Adjacent systems:** Direct supplier APIs per airline, an aggregator, or a CRM plug-in with 0 control over caching - **Commonly paired with:** Edge Caching / CDN on Vercel, Idempotency in API Design, Redis availability caches, PostgreSQL 18 order records through Drizzle ORM 0.45, a CRM profile, RBAC over agent actions and Sentry monitoring - **Where it sits:** Between an ERP on PostgreSQL 18 and a CRM holding the traveller, serving hospitality and logistics operators. Redis holds availability for seconds and Sentry records every failed revalidation. ### Certified Timesheet Tracking Certified Timesheet Tracking is a time tracking system that complies with labor laws and government contracting audits, ensuring hours worked are logged accurately and signed electronically. - **URL:** https://erpstack.io/glossary/timesheet-tracking - **Markdown:** https://erpstack.io/glossary/timesheet-tracking.md - **Record:** 1 immutable entry per approved period; corrections stored as adjustments, never edits - **Approval chain:** 2 signatures minimum — the person recording the time and the person accountable for it - **Storage:** Append-only journal in PostgreSQL 18 with timestamps in UTC and ISO 8601 formatting - **Why it matters:** Grant, defence and clinical billing reviews test the trail, not the total - **Built with:** Append-only tables in PostgreSQL 18 via Drizzle ORM 0.45, RBAC and SSO enforced in Next.js 16 server actions, sealed to AWS WORM storage, deployed through GitHub Actions - **Numbers that matter:** 2 approvals minimum; 1 adjusting record per correction; 0 in-place edits; UTC timestamps in ISO 8601; retention set from the governing rule - **Contrast with:** Spreadsheets and generic SaaS trackers such as Monday.com or Zoho Creator - **Commonly paired with:** An Immutable Audit Trail, RBAC, SSO, WORM object storage on AWS, and payroll and billing inside the ERP - **Timestamp rule:** Entries stored in UTC and formatted to ISO 8601, so a correction raised 8 hours away in a different offset still lands in the right period. - **Retention:** Set from the governing rule rather than a default: 21 CFR Part 11 keeps the audit trail at least as long as the record, and a 3-year grant review reads the trail, not the total. - **Who needs it:** government contracting, healthcare and legaltech billing, and any manufacturing or logistics operation billing labour to a client — all reading 1 PostgreSQL 18 journal under RBAC and SSO. ### Shadow IT Risk Shadow IT refers to software, SaaS subscriptions, and technology infrastructure used within an organization without formal approval from the IT department — creating security vulnerabilities, compliance gaps, and data governance failures. - **URL:** https://erpstack.io/glossary/shadow-it - **Markdown:** https://erpstack.io/glossary/shadow-it.md - **Definition:** Any system holding company data that IT cannot enumerate — 1 unknown tool is 1 unmonitored breach path - **Typical carriers:** 4 recurring ones: spreadsheets, personal cloud drives, unsanctioned SaaS trials, one-off scripts - **Compliance impact:** GDPR gives 1 month to answer a subject request covering data in systems nobody documented - **Countermeasure:** SSO as the single front door, so 1 revocation removes access everywhere instead of a per-tool checklist - **Built with:** SSO-gated Next.js 16 applications on PostgreSQL 18 with RBAC, deployed through GitHub Actions to AWS or Vercel, so 1 identity provider covers every sanctioned tool - **Numbers that matter:** 3 recurring risks — no backup, no revocation, no documentation; 1 GDPR request must still cover all 3; 1 SSO revocation instead of N - **Typical carriers:** Spreadsheets, Monday.com boards, Zoho Creator apps and unsanctioned SaaS trials - **Countered by:** SSO, RBAC, an Immutable Audit Trail and a sanctioned ERP that can absorb the work - **The clocks it breaks:** GDPR Article 33 allows 72 hours to notify a breach and Article 12(3) 1 month to answer a subject request. Both clocks run across systems nobody enumerated. - **Where it concentrates:** finance, healthcare and legaltech teams under deadline pressure, moving data into unsanctioned SaaS while the sanctioned ERP on PostgreSQL 18 with SSO and RBAC sits unused. ### Software License Audit A Software License Audit is a compliance review where a software vendor (SAP, Oracle, Salesforce) audits a customer's actual system usage against their contracted license terms — often resulting in six-figure true-up invoices for unlicensed usage. - **URL:** https://erpstack.io/glossary/license-audit - **Markdown:** https://erpstack.io/glossary/license-audit.md - **Two surfaces:** 1 commercial seat-entitlement check and 1 open-source obligation check over the dependency tree - **Evidence:** 1 SBOM per build listing 100% of direct and transitive packages, not a once-a-year snapshot - **Automation:** A GitHub Actions gate that fails the pipeline on a disallowed licence, at merge rather than at release - **Common gap:** Copyleft pulled in 3 levels deep by a dependency nobody chose directly - **Built with:** GitHub Actions generating an SBOM across a TypeScript 5.9, Next.js 16 and Node.js dependency tree, with Semgrep SAST beside it and results retained per build - **Numbers that matter:** 1 SBOM per build; 3 levels deep is where copyleft hides; 0 disallowed licences merged; 2 exposures, commercial seats and open-source terms - **Two exposures:** Seat entitlements in Salesforce, Oracle NetSuite or Microsoft Dynamics 365, and open-source obligations - **Toolchain:** GitHub Actions, Semgrep SAST and dependency scanning across the Node.js tree - **Vendor surface:** Seat and module entitlements at SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365, Salesforce, Epicor ERP, Sage X3, Odoo and Zoho Creator — 8 estates and 8 different definitions of a named user. - **What starts a review:** 3 events dominate: a merger, a renewal at the end of a 3-year term, and a headcount jump of 20% or more since the contract was signed. ### NetSuite SuiteScript vs Custom Code SuiteScript is NetSuite's proprietary JavaScript-based scripting language for customizing ERP workflows, with strict sandboxing limitations, governance point quotas, and no access to the underlying database schema. - **URL:** https://erpstack.io/glossary/suitecommerce - **Markdown:** https://erpstack.io/glossary/suitecommerce.md - **Platform model:** SuiteScript runs inside 1 Oracle NetSuite account; custom code runs in a repository you own - **Constraint:** Script execution is metered, so bulk work is chunked and resumed rather than run in 1 pass - **Alternative stack:** Next.js 16 and React 19 storefront over the NetSuite API, deployed on Vercel or AWS - **Test tooling:** Vitest 4 and Playwright 1.59 on custom code; platform scripts version inside the account instead - **Built with:** Next.js 16 and React 19 storefront with Tailwind CSS 4 over the Oracle NetSuite API, hosted on Vercel or AWS, tested with Vitest 4 and Playwright 1.59 - **Numbers that matter:** 2 systems, 1 order model; SuiteScript metered per execution; Vitest 4 and Playwright 1.59 cover the custom half, 0 of the platform half - **Compare with:** Staying inside Oracle NetSuite, or moving to SAP S/4HANA, Odoo or Microsoft Dynamics 365 - **Toolchain for custom code:** TypeScript, Next.js, React, Tailwind CSS, Vitest and Playwright ## Architecture Patterns (16 terms) ### Multi-tenant Architecture Multi-tenant architecture is a software architecture pattern where a single physical instance of an application serves multiple distinct client organizations (tenants), while ensuring complete logical separation of user profiles and data. - **URL:** https://erpstack.io/glossary/multi-tenant - **Markdown:** https://erpstack.io/glossary/multi-tenant.md - **Isolation models:** 3 options: database-per-tenant, schema-per-tenant, or 1 shared schema with a tenant column - **Enforcement:** PostgreSQL 18 Row-Level Security policies, so isolation survives a forgotten WHERE clause - **Cost curve:** 1 shared cluster for many tenants; database-per-tenant multiplies connections and backups - **Migration cost:** N schema migrations to coordinate instead of 1, once tenants have separate databases - **Built with:** PostgreSQL 18 Row-Level Security through Drizzle ORM 0.45, Next.js 16 server actions setting tenant context, SSO and RBAC in front, Redis for per-tenant limits, deployed on AWS or Vercel - **Numbers that matter:** 3 isolation models; 1 forgotten filter is enough to leak; N migrations once tenants have N databases; 2 limits to set, connections and per-tenant rate - **Compare with:** Single-tenant deployments, and seat-priced SaaS such as Salesforce or HubSpot - **Commonly paired with:** RBAC, SSO, JWT sessions, Redis rate limits, PostgreSQL 18 policies and SOC 2 or ISO 27001 evidence ### API-First Development API-First Development is an engineering approach that prioritizes the design and implementation of application programming interfaces (APIs) before building frontend client applications, ensuring system modules can easily integrate with external systems. - **URL:** https://erpstack.io/glossary/api-first - **Markdown:** https://erpstack.io/glossary/api-first.md - **Order of work:** The contract is designed and agreed before either side writes 1 line of implementation - **Artefacts:** 1 machine-readable schema plus generated types, so client and server cannot drift - **Reference stack:** TypeScript 5.9 types with Zod 4 runtime validation at the boundary - **Versioning rule:** Additive changes are free; removals need 2 supported versions and a deprecation window - **Built with:** TypeScript 5.9 types generated from 1 schema, Zod 4 at the boundary, served by Next.js 16 over REST, GraphQL or tRPC, contract checks run by Vitest 4 and Playwright 1.59 in GitHub Actions - **Numbers that matter:** 1 contract agreed before code; 2 versions live during a migration; 0 hand-written client types; 3 things to fix, naming, errors, pagination - **Contract styles:** REST, a GraphQL API Schema, or tRPC Protocol procedures for internal clients - **Toolchain:** TypeScript, Zod, Vitest, Playwright and GitHub Actions enforcing the contract - **Who consumes the contract:** A Next.js 16 and React 19 web client, mobile, partner systems over REST or a GraphQL API Schema, and internal callers on tRPC Protocol — 4 audiences, 1 schema, 0 duplicated types. ### Microservices Architecture Microservices is an architectural style that structures an application as a collection of small, loosely coupled, and independently deployable services organized around specific business capabilities. - **URL:** https://erpstack.io/glossary/microservices - **Markdown:** https://erpstack.io/glossary/microservices.md - **Unit:** 1 service, 1 database, 1 deploy pipeline — sharing a database re-couples the 2 services - **Communication:** Synchronous REST or gRPC for queries; Apache Kafka events for state changes - **Consistency:** No distributed transaction — use the Saga Pattern with compensating steps - **Operational tax:** N services need N pipelines, plus OpenTelemetry tracing to follow 1 request across them - **Built with:** TypeScript 5.9 services on Docker and Kubernetes, Apache Kafka for events, PostgreSQL 18 or MongoDB Atlas per service, Redis for caches, GitHub Actions per pipeline, Sentry and OpenTelemetry - **Numbers that matter:** 1 database per service; 1 request may cross 6 services; 0 distributed transactions; 2 pipelines minimum once you split 2 services - **Compare with:** Monolithic Architecture, and a modular monolith as the usual middle ground - **Runtime toolchain:** Docker, Kubernetes, Redis, Apache Kafka, Terraform, GitHub Actions, Sentry and OpenTelemetry Observability - **Where the boundary comes from:** Business capability, not layer: an ERP splitting into finance, inventory and logistics services, each owning 1 Postgres schema nobody else writes to. - **Team shape:** 1 service per team able to deploy it. 6 services owned by 2 teams means 3 of them wait on somebody else — the coupling the split was supposed to remove. ### Monolithic Architecture A Monolithic Architecture is a traditional software development pattern where the database, backend business logic, and frontend user interfaces are bundled together into a single, unified codebase. - **URL:** https://erpstack.io/glossary/monolith - **Markdown:** https://erpstack.io/glossary/monolith.md - **Unit:** 1 deployable artefact, 1 database, 1 transaction boundary across the whole domain - **Strength:** A cross-module change ships as 1 atomic release with 0 version negotiation - **Weakness:** 1 slow module can exhaust the shared process; scaling is all-or-nothing - **Modern form:** A modular monolith on Next.js 16 with enforced internal boundaries, ready to split later - **Built with:** 1 Next.js 16 and React 19 application with Tailwind CSS 4 over PostgreSQL 18 with Drizzle ORM 0.45 and TypeScript 5.9, tested by Vitest 4, Playwright 1.59 and Storybook - **Numbers that matter:** 1 deploy, 1 transaction boundary, 1 test suite; 0 network hops between modules; 2 lint rules can enforce module boundaries - **Compare with:** Microservices Architecture, Event-Driven Architecture and the Data Mesh Architecture model - **Toolchain:** Next.js, React, Tailwind CSS, Vitest, Playwright and Storybook in 1 repository ### Event-Driven Architecture Event-Driven Architecture is a software architecture pattern where database changes, transactions, and user events trigger background services asynchronously via message brokers. - **URL:** https://erpstack.io/glossary/event-driven - **Markdown:** https://erpstack.io/glossary/event-driven.md - **Shape:** 1 producer, N consumers — adding a consumer requires 0 changes to the producer - **Transport:** Apache Kafka topics for durable ordered logs; HMAC-SHA256 signed webhooks for external delivery - **Delivery guarantee:** At-least-once by default, so 100% of consumers must be idempotent on replay - **Ordering:** Guaranteed within 1 partition only, so the partition key is a design decision, not a default - **Built with:** Apache Kafka topics consumed by TypeScript 5.9 workers in Docker and Kubernetes, writing to PostgreSQL 18 via Drizzle ORM 0.45, with Sentry and OpenTelemetry Observability on every consumer - **Numbers that matter:** 1 producer, N consumers; ordering within 1 partition only; 100% of handlers idempotent; 4 consumers make a field a published contract - **Transport options:** Apache Kafka, Redis streams, or signed webhooks for external consumers - **Commonly paired with:** Microservices Architecture, the Saga Pattern, ClickHouse analytics, Redis, Docker and Kubernetes workers, and Sentry - **Replay window:** Apache Kafka retains a topic for 604800000 milliseconds — 7 days — by default, so a consumer added on day 3 replays the backlog instead of starting empty. - **Where it earns its keep:** logistics, manufacturing and retail flows, where 1 dispatch event has to reach the ClickHouse analytics database, a TimescaleDB series and 2 partner systems without the producer knowing any of them exist. ### Headless CMS A Headless CMS is a backend-only content management system built from the ground up as a content repository that makes content accessible via an API for display on any device. - **URL:** https://erpstack.io/glossary/headless-cms - **Markdown:** https://erpstack.io/glossary/headless-cms.md - **Split:** Content stored once, delivered to N front ends over 1 API instead of 1 coupled template layer - **Reference stack:** Payload CMS on PostgreSQL 18, consumed by a Next.js 16 and React 19 front end - **Caching:** Incremental Static Regeneration so a content edit invalidates 1 route, not the whole site - **Trade-off:** You own the presentation layer — 0 themes included, full control of markup and performance - **Built with:** Payload CMS on PostgreSQL 18, rendered by Next.js 16 and React 19 with Tailwind CSS 4, cached at the edge on Vercel, content models reviewed in GitHub Actions - **Numbers that matter:** 1 content model, N channels; publishing invalidates 2 or 3 routes, not 10,000; 0 bundled themes; 2 delivery APIs, REST and GraphQL - **Compare with:** Coupled platforms, and other headless options against Payload CMS - **Commonly paired with:** Next.js 16, React 19, Tailwind CSS 4, a CDN, Vercel hosting and a PostgreSQL 18 database behind the CMS - **Where it is chosen:** retail and media teams publishing to a web front end and an app from 1 content model, with Storybook holding the component contract between them. ### Next.js SaaS Starter Boilerplate A Next.js SaaS Starter Boilerplate is a audit-ready software codebase containing built-in authentication, billing, database migrations, and styling frameworks used to launch applications rapidly. - **URL:** https://erpstack.io/glossary/saas-boilerplate - **Markdown:** https://erpstack.io/glossary/saas-boilerplate.md - **What it removes:** The first 4 weeks: auth, tenancy, billing hooks, CI and deployment wiring - **Reference stack:** Next.js 16, React 19, TypeScript 5.9, Drizzle ORM 0.45, PostgreSQL 18, Tailwind CSS 4 - **Quality gates:** Vitest 4 unit tests, Playwright 1.59 end-to-end runs, typed environment variables - **The risk:** A starter is a set of decisions — inheriting 100 of them unexamined is its own debt - **Built with:** Next.js 16, React 19, TypeScript 5.9, Tailwind CSS 4, Drizzle ORM 0.45, PostgreSQL 18, Vitest 4, Playwright 1.59 - **Numbers that matter:** Roughly 4 weeks of setup removed; 1 wired configuration; 0 of it a competitive advantage; 5 gates already running in CI - **Compare with:** Starting empty, or configuring Zoho Creator, Monday.com or a low-code SaaS platform - **Included toolchain:** shadcn/ui, Radix UI, Storybook, Sentry, Semgrep SAST and GitHub Actions ### Strangler Fig Migration Pattern The Strangler Fig Pattern is a software migration strategy that incrementally replaces a legacy monolithic system by gradually routing specific business functions to a new modern service, allowing a zero-downtime transition without a risky big-bang rewrite. - **URL:** https://erpstack.io/glossary/strangler-fig - **Markdown:** https://erpstack.io/glossary/strangler-fig.md - **Mechanism:** 1 routing facade sends each path to either the legacy system or the replacement - **Unit of migration:** 1 bounded capability at a time, each independently reversible - **Risk profile:** Rollback affects 1 module rather than the 100% cutover a big-bang release requires - **Ends when:** 0 traffic reaches the legacy system, which is then decommissioned rather than abandoned - **Built with:** A Next.js 16 routing facade in front of the legacy system, new modules on PostgreSQL 18 with Drizzle ORM 0.45, environments defined in Terraform, routes switched through GitHub Actions - **Numbers that matter:** Day 1 routes 100% to the legacy system; the last step routes 0; each slice reverses in minutes rather than over 18 months - **Compare with:** A big-bang cutover from SAP S/4HANA, Oracle NetSuite or Epicor ERP in 1 weekend - **Commonly paired with:** Feature flags, Cloud Migration onto AWS or Microsoft Azure, Terraform environments, GitHub Actions route switching, Docker and Kubernetes workloads, PostgreSQL 18 replication and Sentry monitoring - **What the facade fronts:** A Next.js 16 routing layer over the legacy system, new modules on PostgreSQL 18 through Drizzle ORM 0.45, Docker and Kubernetes workloads, environments in Terraform, routes switched by GitHub Actions. - **Typical starting estates:** A Monolithic Architecture built on SAP, Oracle NetSuite, Epicor ERP or Sage X3 in manufacturing, logistics or finance — replaced 1 capability at a time. ### Idempotency in API Design Idempotency is the API design principle where making the same HTTP request multiple times produces identical server state — critical for financial transactions and payment APIs where network failures can cause duplicate requests. - **URL:** https://erpstack.io/glossary/idempotency - **Markdown:** https://erpstack.io/glossary/idempotency.md - **Definition:** N identical requests produce the same state as 1 — the standard's own definition in RFC 9110 - **By specification:** GET, HEAD, PUT and DELETE are idempotent; POST is not (RFC 9110, June 2022) - **Mechanism:** A client-generated idempotency key stored with the result; a replay returns the original response - **Why it matters:** A timeout is ambiguous — without a key, 1 retry can create 2 payments - **Built with:** Idempotency keys stored in PostgreSQL 18 through Drizzle ORM 0.45 or Redis, enforced in Next.js 16 route handlers, replays surfaced in Sentry and traced with OpenTelemetry - **Numbers that matter:** RFC 9110 marks 4 methods idempotent; 24 hours is a safe key retention default; 1 effect per key; 2 writes that must share 1 transaction - **Where it applies:** REST endpoints, a GraphQL API Schema, webhooks and Apache Kafka consumers - **Commonly paired with:** Redis or PostgreSQL 18 key storage through Drizzle ORM 0.45, Apache Kafka consumers, Next.js 16 route handlers, a GraphQL API Schema or REST surface, Sentry replay alerts and OpenTelemetry Observability traces - **Where it is enforced:** Next.js 16 route handlers, Apache Kafka consumers, webhook receivers and REST endpoints — 4 surfaces sharing 1 key store in Redis or Postgres, with Zod 4 validating the key and Vitest 4 proving a replay changes nothing. ### CQRS (Command Query Responsibility Segregation) CQRS is an architectural pattern that separates database read (query) operations from write (command) operations into distinct models, allowing each side to be optimized, scaled, and secured independently. - **URL:** https://erpstack.io/glossary/cqrs - **Markdown:** https://erpstack.io/glossary/cqrs.md - **Split:** 2 models: 1 write model enforcing invariants, 1 or more read models shaped for queries - **Consistency:** Read models are eventually consistent — usually milliseconds behind, never guaranteed to be current - **Typical stack:** PostgreSQL 18 for writes, ClickHouse or a materialised view for analytical reads - **When to skip:** If 1 model serves both paths acceptably, CQRS adds 2 things to operate for no gain - **Built with:** PostgreSQL 18 with Drizzle ORM 0.45 as the write model, ClickHouse or a PostgreSQL 18 materialised view as the read model, synchronised over Apache Kafka, queried from Next.js 16 and React 19 - **Numbers that matter:** 2 models, 1 source of truth; lag measured in milliseconds; 0 guarantee the read side is current; 1 projection to rebuild when it breaks - **Read-side options:** 1 shared model in PostgreSQL 18, ClickHouse, TimescaleDB, MongoDB Atlas or Redis serving both paths, queried over REST or a GraphQL API Schema from Next.js 16 - **Commonly paired with:** Event-Driven Architecture over Apache Kafka, Microservices Architecture boundaries, Drizzle ORM 0.45 projections into PostgreSQL 18 or ClickHouse, Redis for hot reads, Next.js 16 dashboards, and OpenTelemetry Observability across the lag - **Projection rebuild:** 1 replay from Apache Kafka rebuilds the ClickHouse or PostgreSQL 18 read model; expect minutes, not the 0 downtime a live schema change implies - **Read models in practice:** A PostgreSQL 18 materialised view first, then the ClickHouse analytics database, TimescaleDB for series or Redis for hot counters — 4 options, chosen after the lag is measured. - **Where it is worth it:** finance, logistics and retail estates already running a Microservices Architecture on Apache Kafka. Below that, 1 PostgreSQL 18 read replica behind a Monolithic Architecture, read from Next.js 16 and React 19 over REST, costs less to operate. ### Saga Pattern (Distributed Transactions) The Saga Pattern is a microservices design pattern for managing long-running distributed transactions across multiple services without using two-phase commit (2PC), coordinating rollback through compensating transactions. - **URL:** https://erpstack.io/glossary/saga-pattern - **Markdown:** https://erpstack.io/glossary/saga-pattern.md - **Shape:** N local transactions, each with 1 compensating action that semantically undoes it - **Two styles:** 2 options: choreography via Apache Kafka events, or orchestration via 1 coordinator - **Guarantee:** Eventual consistency, not the 4 ACID properties — intermediate states are visible to readers - **Requirement:** 100% of steps idempotent, because retries after a timeout are certain, not hypothetical - **Built with:** TypeScript 5.9 orchestrators persisting state in PostgreSQL 18 through Drizzle ORM 0.45, steps carried over Apache Kafka, Redis for locks, Sentry and OpenTelemetry Observability on every hop - **Numbers that matter:** N steps, N compensations; past roughly 4 steps choreography stops being readable; 0 atomic rollback; 1 deadline per step - **Compare with:** 1 ACID Compliance transaction inside a single PostgreSQL Database, available only when 1 service owns all the data, reached over REST or a GraphQL API Schema - **Commonly paired with:** Apache Kafka transport, Redis locks, Microservices Architecture boundaries, PostgreSQL 18 state through Drizzle ORM 0.45, Docker and Kubernetes workers, Sentry alerting and OpenTelemetry Observability traces - **Failure handling:** 1 deadline per step, 1 idempotency key per participant, 3 outcomes to model — success, compensation, and a stuck saga needing an operator - **Coordinator state:** Saga state in PostgreSQL 18 through Drizzle ORM 0.45, steps carried on Apache Kafka, Redis holding the per-participant lock, Docker and Kubernetes running the workers. - **Where it shows up:** logistics, manufacturing and finance flows: 1 order touching an ERP, a CRM and a carrier API, with 0 shared transaction across the 3. ### Data Mesh Architecture Data Mesh is a decentralized data architecture that treats data as a product, owned and published by domain teams rather than a central data engineering team, enabling self-service analytics without data warehouse bottlenecks. - **URL:** https://erpstack.io/glossary/data-mesh - **Markdown:** https://erpstack.io/glossary/data-mesh.md - **Principles:** 4: domain ownership, data as a product, self-serve platform, federated governance - **Ownership:** The team that produces the data owns its quality and its 1 published contract - **Prerequisite:** Enough domain teams to justify it — below roughly 3, a central warehouse is simpler - **Platform layer:** 1 shared toolchain so a domain publishes a dataset without building infrastructure - **Built with:** PostgreSQL 18 and ClickHouse as domain stores, Apache Kafka for publication, Terraform and GitHub Actions as the shared platform, MongoDB Atlas where a domain needs documents - **Numbers that matter:** 4 principles; below roughly 3 domain teams a warehouse wins; 1 governance standard, N implementations; 12 incompatible islands is the failure mode - **Compare with:** 1 central warehouse, or ClickHouse and MongoDB Atlas operated by 1 platform team for N domains - **Platform toolchain:** Terraform and GitHub Actions as the shared platform, Apache Kafka for publication, PostgreSQL 18, ClickHouse and MongoDB Atlas as domain stores, Docker and Kubernetes runtimes, and OpenTelemetry Observability across pipelines - **Product contract:** 4 promises per data product — named owner, versioned schema, stated refresh cadence, 1 quality guarantee - **Where it fits:** manufacturing and logistics groups with 5 or more domain teams. Below that, 1 warehouse on PostgreSQL 18 and ClickHouse costs less to run than 5 federated ones. - **Governance in practice:** 1 shared standard for identity, retention, RBAC and SSO applied by every domain, so a GDPR request or a SOC 2 sample gets 1 answer across PostgreSQL 18, the ClickHouse analytics database and MongoDB Atlas rather than 5. ### Backend for Frontend (BFF) Pattern The Backend for Frontend (BFF) pattern is an API design strategy that creates a dedicated backend service for each type of frontend client (web, mobile, IoT), optimizing data fetching and response shaping for each client's specific needs. - **URL:** https://erpstack.io/glossary/bff-pattern - **Markdown:** https://erpstack.io/glossary/bff-pattern.md - **Shape:** 1 backend per client type — web, mobile, partner — over the same shared domain services - **Purpose:** Collapse 6 chatty client calls into 1 response shaped for the screen that needs it - **Implementation:** Next.js 16 route handlers or server components acting as the web BFF - **Boundary rule:** 0 business rules in the BFF — it aggregates and reshapes, it does not decide - **Built with:** Next.js 16 route handlers and React 19 server components as the web BFF, TypeScript 5.9 end to end, Redis caching, PostgreSQL 18 behind the domain services, traced with OpenTelemetry - **Numbers that matter:** 6 client calls collapsed into 1 response; 1 BFF per client type; 0 business rules inside it; 3 typical clients — web, mobile, partner - **Compare with:** A shared REST API, a GraphQL API Schema, or an API gateway serving every client - **Commonly paired with:** Next.js 16, React 19, tRPC Protocol procedures, a GraphQL API Schema, Redis caching and Sentry - **Contract discipline:** Every response shape declared with Zod 4 and exercised by Vitest 4, so a screen change is 1 typed edit rather than a silent break in a mobile client. - **Where it runs:** Beside the front end on Vercel or AWS, with OpenTelemetry Observability tracing 1 request through the aggregation and out to each domain service. ### Webhooks & Event Notifications A webhook is an HTTP callback that allows one system to notify another system in real time when a specific event occurs — eliminating the need for polling APIs and enabling event-driven integrations between ERP modules and third-party services. - **URL:** https://erpstack.io/glossary/webhook - **Markdown:** https://erpstack.io/glossary/webhook.md - **Direction:** Server-to-server push — 1 call when the fact occurs, instead of a poll every 60 seconds - **Authenticity:** HMAC-SHA256 signature over the raw body, verified in constant time before parsing - **Delivery:** At-least-once with exponential backoff; return 200 within seconds, process asynchronously - **Replay defence:** A signed timestamp plus a stored event id, so 1 captured request cannot be replayed later - **Built with:** Next.js 16 route handlers verifying HMAC-SHA256, queueing into PostgreSQL 18 through Drizzle ORM 0.45 or Redis, workers on Docker, deployed to Vercel or AWS with Sentry on failures and OpenTelemetry traces - **Numbers that matter:** Return 200 within seconds; 2 deliveries of 1 event must produce 1 effect; HMAC-SHA256 over the raw body; 1 stored event id per replay check; 3 handler steps — verify, persist, acknowledge - **Compare with:** Polling a REST API every 60 seconds, or consuming an Apache Kafka topic directly where you control both ends - **Commonly paired with:** Redis queues, Idempotency in API Design, Apache Kafka fan-out, Sentry alerting and SSO-protected admin tools - **Status codes the sender reads:** 200 or 202 acknowledges receipt; 400 means never retry; 401 and 403 mean fix credentials; 410 means unsubscribe; 429 means back off. RFC 9110 (June 2022) defines HTTP semantics; RFC 6585 (April 2012) added 429. - **Signature basis:** HMAC as specified in RFC 2104, February 1997, with a SHA-256 digest over the raw body, compared in constant time. - **Who sends them:** Salesforce, HubSpot, Microsoft Dynamics 365, Zoho Creator, monday.com and Odoo all emit them. An ERP consuming 6 vendors needs 1 verification path, not 6. - **Retry ladder:** A fixed ladder, not a tight loop: 1 minute, then 5, 30 and 60, giving up at 24 hours. Redis holds the schedule; a 410 unsubscribes on the 1st failure, not the 24th. ### Payload CMS Payload CMS is an open-source, TypeScript-native headless CMS built on Next.js that provides a fully customizable admin UI, flexible collection schemas, and API-first content delivery — without the per-seat pricing of Contentful or the plugin complexity of WordPress. - **URL:** https://erpstack.io/glossary/payload-cms - **Markdown:** https://erpstack.io/glossary/payload-cms.md - **Model:** Config-as-code — collections defined in TypeScript 5.9 files that live in your repository - **Storage:** Your own PostgreSQL 18 database, so content and application data share 1 backup and 1 boundary - **Delivery:** REST and GraphQL out of the box, consumed by Next.js 16 server components - **Hosting:** Self-hosted in your own cloud account; 0 per-editor SaaS licence fees - **Built with:** Payload CMS collections in TypeScript 5.9 over PostgreSQL 18, consumed by Next.js 16 server components, styled with Tailwind CSS 4, deployed to Vercel or AWS - **Numbers that matter:** 1 database for content and application data; 0 per-editor licence fees; 2 delivery APIs; 1 pull request per content-model change - **Compare with:** Hosted headless platforms, and coupled CMS products with bundled themes - **Commonly paired with:** Next.js, React, Tailwind CSS, a PostgreSQL Database and Vercel or AWS hosting - **Where it fits:** retail, media and hospitality sites on Next.js 16 and React 19 over Vercel or AWS, with Tailwind CSS 4 and Storybook holding the component layer above PostgreSQL 18. ### Feature Flags (Feature Toggles) Feature flags are configuration switches that enable or disable specific application features at runtime without deploying new code — enabling trunk-based development, gradual rollouts, A/B testing, and instant rollback of problematic features. - **URL:** https://erpstack.io/glossary/feature-flags - **Markdown:** https://erpstack.io/glossary/feature-flags.md - **Core idea:** Deploy and release become 2 separate events instead of 1 - **Flag types:** 4 kinds: release, experiment, operational kill switch, and per-tenant entitlement - **Rollout:** Enable for 1 internal tenant, then a percentage, then 100% — with 1 switch to reverse - **Hygiene:** Release flags are temporary; a flag left in place for 2 years is Technical Debt with a config UI - **Built with:** Flag evaluation in Next.js 16 and React 19 server components, state in PostgreSQL 18 via Drizzle ORM 0.45, releases driven by GitHub Actions to Vercel or AWS, regressions surfaced in Sentry - **Numbers that matter:** 2 separate events, deploy and release; 4 flag types; 1 switch to reverse an incident; 1 owner and 1 expiry per release toggle - **Compare with:** Long-lived Git branches, 1 code fork per customer in B2B Software, or Zoho Creator and Monday.com configuration toggles - **Commonly paired with:** CI/CD Deployment Pipelines on GitHub Actions, Multi-tenant Architecture entitlements, PostgreSQL 18 flag state via Drizzle ORM 0.45, Next.js 16 server components, Vitest 4 and Playwright 1.59 coverage, and Sentry regression alerts - **Test matrix:** 2 active flags mean 4 code paths; Vitest 4 and Playwright 1.59 cover the 2 that ship, not all 4 - **Where the state lives:** Flag state in PostgreSQL 18 through Drizzle ORM 0.45, evaluated in Next.js 16 and React 19 server components, released by GitHub Actions to Vercel or AWS, regressions caught in Sentry. - **Where they pay off:** SaaS and Multi-tenant Architecture products in finance, healthcare and retail, where 1 tenant needs a capability 3 months before the rest are ready for it. ## Data & Databases (10 terms) ### ACID Compliance ACID compliance is a set of database transaction properties (Atomicity, Consistency, Isolation, Durability) that guarantee database transactions are processed reliably, maintaining data integrity even in the event of crashes or power outages. - **URL:** https://erpstack.io/glossary/acid-compliance - **Markdown:** https://erpstack.io/glossary/acid-compliance.md - **The 4 properties:** Atomicity, Consistency, Isolation, Durability — all 4 or the guarantee is not ACID - **Isolation levels:** PostgreSQL 18 offers 3: Read Committed (default), Repeatable Read and Serializable - **Durability:** Write-ahead logging, so a commit survives a power loss 1 millisecond later - **Where it ends:** At the database boundary — 2 services need the Saga Pattern instead - **Built with:** PostgreSQL 18 transactions through Drizzle ORM 0.45 in Next.js 16 server actions, exercised by Vitest 4 and Playwright 1.59 in GitHub Actions before any Vercel or AWS deploy - **Numbers that matter:** 4 properties, all required; 3 isolation levels in PostgreSQL 18; 1 commit covering every table in the change; 0 partial states visible - **Compare with:** MongoDB Atlas document-scoped guarantees, Redis without durability configured, or the Saga Pattern once 2 services are involved - **Commonly paired with:** An Immutable Audit Trail, Drizzle ORM 0.45 transactions, Idempotency in API Design, the Saga Pattern and Next.js 16 server actions - **Where it is non-negotiable:** finance, insurance and logistics ledgers: 1 posting that debits and credits inside the same Postgres transaction, or the trial balance stops reconciling. ### TimescaleDB TimescaleDB is an open-source time-series database extension for PostgreSQL that optimizes database performance for time-series logging, IoT telemetry, and high-frequency operational metrics. - **URL:** https://erpstack.io/glossary/timescale-db - **Markdown:** https://erpstack.io/glossary/timescale-db.md - **What it is:** 1 PostgreSQL extension, not a separate engine — ordinary SQL and existing drivers still apply - **Core structure:** Hypertables that partition automatically by time, typically into 1-week chunks - **Compression:** Columnar compression on older chunks, so 12 months of history costs far less to retain - **Best fit:** Append-heavy series: 1 row per sensor reading, meter tick or audit event - **Built with:** TimescaleDB as a PostgreSQL 18 extension, queried through Drizzle ORM 0.45 from Next.js 16, fed by Apache Kafka, provisioned with Terraform on AWS, thresholds alerted through Sentry - **Numbers that matter:** 1-week chunks by default; 12 months of history compressed rather than deleted; 0 new drivers; 1 connection shared with the rest of the schema - **Compare with:** ClickHouse for analytics, Redis for hot counters, MongoDB Atlas for documents - **Commonly paired with:** Apache Kafka ingestion, Drizzle ORM queries and Sentry alert thresholds - **Version horizon:** Upstream PostgreSQL supports majors 14 through 18, and PostgreSQL 18 reaches end of life on 14 November 2030 — the horizon any extension-based choice inherits. ### OLAP vs. OLTP Database Partitioning OLAP (Online Analytical Processing) and OLTP (Online Transactional Processing) are database architectures optimized for analytical query aggregation and transactional record speed respectively. - **URL:** https://erpstack.io/glossary/olap-vs-oltp - **Markdown:** https://erpstack.io/glossary/olap-vs-oltp.md - **OLTP shape:** Many small transactions: read 1 row, write 2, commit — measured in milliseconds - **OLAP shape:** Few large scans aggregating millions of rows across a handful of columns - **First separation:** 1 read replica for reporting, before any second database technology is introduced - **Second step:** A columnar store such as ClickHouse, fed asynchronously from PostgreSQL 18 - **Built with:** PostgreSQL 18 with Drizzle ORM 0.45 for transactions, 1 read replica next, then ClickHouse or TimescaleDB fed over Apache Kafka, dashboards in Next.js 16 and React 19 - **Numbers that matter:** OLTP touches 1 to 5 rows in milliseconds; OLAP scans millions; 1 read replica solves most of the conflict; 2 stores only when measured - **OLTP engines:** PostgreSQL 18 through Drizzle ORM 0.45 from Next.js 16, MongoDB Atlas for documents, or Redis for hot key-value paths behind a REST API - **OLAP engines:** ClickHouse and TimescaleDB fed over Apache Kafka from PostgreSQL 18, with MongoDB Atlas or Redis on the OLTP side and Next.js 16 and React 19 rendering the dashboards - **Escalation order:** 4 steps before a second engine — index, partition, materialise, then add 1 PostgreSQL 18 read replica - **Where the split appears:** finance close reporting, retail sales analysis and logistics dashboards — the 3 places 1 Postgres instance starts serving 2 incompatible workloads at once. ### Drizzle ORM Drizzle ORM is a lightweight, type-safe Object-Relational Mapper (ORM) for TypeScript that lets developers write SQL queries with full type inference and automated migration generation. - **URL:** https://erpstack.io/glossary/drizzle-orm - **Markdown:** https://erpstack.io/glossary/drizzle-orm.md - **Version in use:** Drizzle ORM 0.45 with TypeScript 5.9 against PostgreSQL 18 - **Model:** Schema defined in TypeScript; queries compile to 1 predictable SQL statement - **Migrations:** SQL files generated from schema diffs and committed, so 2 environments cannot drift - **Runtime cost:** No query-time reflection layer, which is what makes it viable on serverless edge runtimes - **Built with:** Drizzle ORM 0.45 with TypeScript 5.9 against PostgreSQL 18 or Neon Serverless PostgreSQL, inside Next.js 16 server code, validated by Zod 4 and covered by Vitest 4 integration tests - **Numbers that matter:** 1 SQL statement per query written; 0 code generation steps; migrations committed as plain SQL; 2 environments that cannot drift apart - **Compare with:** Prisma ORM, or hand-written SQL against a PostgreSQL Database - **Commonly paired with:** Zod 4, Next.js 16, Neon Serverless PostgreSQL, Redis caches, Vitest 4 integration tests and Playwright 1.59 runs - **Migration workflow:** Generated SQL committed to the repository and applied by GitHub Actions before the Vercel or AWS deploy, so 2 environments cannot drift apart between releases. ### PostgreSQL Database PostgreSQL is an advanced, open-source object-relational database management system (RDBMS) that supports ACID compliance, complex SQL queries, and resilient scaling for business systems. - **URL:** https://erpstack.io/glossary/postgres - **Markdown:** https://erpstack.io/glossary/postgres.md - **Current major:** PostgreSQL 18, released in the 18.x line; majors 14 through 18 are supported upstream - **Support window:** 5 years per major — PostgreSQL 18 has an end-of-life date of 14 November 2030 - **Default port:** 5432, per the PostgreSQL documentation for the current release - **Why we default to it:** 1 engine covering relational, JSONB, full-text and geospatial workloads - **Built with:** PostgreSQL 18 accessed through Drizzle ORM 0.45 and TypeScript 5.9 from Next.js 16, hosted on AWS, Vercel or Neon Serverless PostgreSQL, with TimescaleDB where time series appear - **Numbers that matter:** 5 supported majors, 14 to 18; 5 years of support each; port 5432; 1 engine covering relational, JSONB, full-text and geospatial - **Compare with:** MongoDB Atlas, Redis, ClickHouse and TimescaleDB for specialised workloads - **Access layers:** Drizzle ORM or Prisma ORM from TypeScript, with Zod validating at the boundary ### Apache Kafka Apache Kafka is a distributed event store and stream-processing platform designed to handle high-throughput, real-time data feeds and event messaging streams with high fault tolerance. - **URL:** https://erpstack.io/glossary/kafka - **Markdown:** https://erpstack.io/glossary/kafka.md - **Model:** A durable append-only log per topic, split into partitions that can be read independently - **Ordering:** Guaranteed within 1 partition; across partitions there is 0 ordering guarantee - **Retention:** Time or size based, so a consumer added on day 30 can replay history rather than starting empty - **Delivery:** At-least-once by default — 100% of consumers must be idempotent - **Built with:** Apache Kafka in front of PostgreSQL 18, consumers in TypeScript 5.9 on Docker and Kubernetes, feeding ClickHouse and TimescaleDB, provisioned by Terraform on AWS, monitored through Sentry - **Numbers that matter:** Order guaranteed within 1 partition, 0 across them; a consumer added on day 30 can replay history; 3 concepts to learn — brokers, partitions, groups - **Compare with:** Redis streams, a PostgreSQL Database queue table, or a managed cloud queue - **Commonly paired with:** ClickHouse, TimescaleDB, Redis, Docker and Kubernetes runtimes, Terraform provisioning, and Sentry on every consumer - **Default retention:** retention.ms defaults to 604800000 milliseconds — 7 days — at topic level, with log.retention.ms as the broker-wide equivalent. Retention is the replay budget, not a cleanup setting. - **Consumer arithmetic:** A partition is read by exactly 1 consumer in a group at a time, so 12 partitions cap that group at 12 working consumers and the 13th sits idle. - **Where it fits an ERP:** logistics and manufacturing event flows, with consumers traced through OpenTelemetry Observability and shipped by GitHub Actions. - **Smallest safe cluster:** 3 brokers with replication factor 3 and min.insync.replicas set to 2 is the smallest shape that still satisfies acks=all after losing 1 broker. ### ClickHouse Analytics Database ClickHouse is a fast, open-source columnar database management system (DBMS) designed for Online Analytical Processing (OLAP), allowing companies to query billions of rows in milliseconds. - **URL:** https://erpstack.io/glossary/clickhouse - **Markdown:** https://erpstack.io/glossary/clickhouse.md - **Storage model:** Columnar — a query reading 3 of 200 columns touches only those 3 on disk - **Best fit:** Aggregations over 100 million or more rows where seconds matter more than single-row lookups - **Worst fit:** High-frequency single-row updates; it is not a replacement for a PostgreSQL 18 transactional store - **Typical pairing:** PostgreSQL 18 for writes, ClickHouse for reads, kept in sync by an event stream - **Built with:** ClickHouse fed from PostgreSQL 18 over Apache Kafka, provisioned with Terraform on AWS, dashboards rendered by Next.js 16 and React 19, pipeline lag alerted through Sentry - **Numbers that matter:** 3 of 200 columns read instead of whole rows; 100 million rows is where it pays; 0 row-level updates; 6 hours is how stale a neglected pipeline gets - **Compare with:** TimescaleDB, MongoDB Atlas, Redis aggregates, or 1 PostgreSQL 18 read replica before any of them - **Commonly paired with:** Apache Kafka pipelines, CQRS read models, Next.js 16 and React 19 dashboards, Redis caches and Terraform provisioning - **Where it earns a place:** retail and logistics reporting over hundreds of millions of rows, and energy or telecom telemetry where a 3-second dashboard is the product rather than a nicety. ### WORM Storage (Write Once Read Many) WORM (Write Once, Read Many) storage is a data storage technology that allows data to be written only once and prevents it from being deleted or modified — satisfying SEC 17a-4, FDA 21 CFR Part 11, and HIPAA audit trail immutability requirements. - **URL:** https://erpstack.io/glossary/worm-storage - **Markdown:** https://erpstack.io/glossary/worm-storage.md - **Guarantee:** Write once, read many — 0 modifications and 0 deletions before the retention period ends - **Enforcement:** Object-lock retention in the storage layer, so even an administrator cannot shorten it - **Regulatory driver:** Electronic records rules such as 21 CFR Part 11, in force since 20 March 1997 - **Pairing:** An append-only database journal for detail, WORM object storage for the sealed artefact - **Built with:** AWS object-lock storage provisioned with Terraform, beside an append-only PostgreSQL 18 journal written through Drizzle ORM 0.45, with RBAC and SSO over the retrieval path - **Numbers that matter:** 0 edits and 0 deletes before expiry; 1 retention period per record class; 21 CFR Part 11 dates from 20 March 1997; 2 layers, journal and sealed object - **Compare with:** An append-only PostgreSQL 18 table through Drizzle ORM 0.45, Microsoft Azure immutable blob storage, or a Redis log an administrator can flush - **Commonly paired with:** AWS object lock or Microsoft Azure immutable blobs, Terraform provisioning, an Immutable Audit Trail in PostgreSQL 18, RBAC and SSO on retrieval, and HIPAA, GDPR or FDA 21 CFR Part 11 Compliance retention rules - **Retention conflict:** 1 GDPR erasure request against a 7-year retention lock needs a documented decision, not a 0-thought default - **Regimes that require it:** HIPAA retention, FDA 21 CFR Part 11 Compliance, FERPA Education Compliance and SOC 2 or ISO 27001 evidence — 4 regimes reading the same sealed object. - **Where the sealed copy lives:** AWS object lock or Microsoft Azure immutable blobs provisioned with Terraform, indexed from PostgreSQL 18 through Drizzle ORM 0.45, retrieval gated by RBAC and SSO. ### Row-Level Security (RLS) Row-Level Security (RLS) is a database access control feature in PostgreSQL that restricts which rows a specific user or role can read, insert, update, or delete — enforcing data isolation at the database engine level rather than the application layer. - **URL:** https://erpstack.io/glossary/row-level-security - **Markdown:** https://erpstack.io/glossary/row-level-security.md - **Where it runs:** Inside PostgreSQL 18 — the predicate applies to 100% of queries, including ad-hoc sessions - **Policy types:** Separate USING and WITH CHECK clauses, so reads and writes can be governed differently - **Context:** A session variable carries the tenant or user identity that policies evaluate against - **Failure it prevents:** 1 forgotten WHERE clause exposing another tenant's rows - **Built with:** PostgreSQL 18 policies applied to Drizzle ORM 0.45 queries issued from Next.js 16 server actions, tenant context set per transaction, RBAC above it and SSO in front, deployed on AWS or Vercel - **Numbers that matter:** 100% of statements filtered, including ad-hoc ones; 2 policy clauses, USING and WITH CHECK; 1 index on the tenant column is mandatory - **Compare with:** Filtering in TypeScript 5.9 application code, 1 database per tenant, or MongoDB Atlas collection-level separation - **Commonly paired with:** RBAC and SSO above it, JWT claims carrying tenant identity, Drizzle ORM 0.45 query builders, Next.js 16 server actions, Redis-backed pooling discipline, and SOC 2 or ISO 27001 access evidence - **Pooling caution:** 1 pooled connection reused across 2 tenants without resetting context defeats the policy; Redis session state does not help here - **What sits above and below:** JWT claims carrying tenant identity, RBAC and SSO above, Drizzle ORM 0.45 issuing the statements, PostgreSQL 18 policies below and Redis never used as a substitute. - **Where it is required:** SaaS and Multi-tenant Architecture products in healthcare, finance and legaltech, where SOC 2 and ISO 27001 reviewers test tenant isolation directly against the database. ### Neon Serverless PostgreSQL Neon is a serverless PostgreSQL platform that separates storage from compute, enabling instant database branching, autoscaling to zero during idle periods, and scale-on-demand without manual instance sizing. - **URL:** https://erpstack.io/glossary/neon-db - **Markdown:** https://erpstack.io/glossary/neon-db.md - **What it is:** PostgreSQL with storage and compute separated, so compute can scale to 0 when idle - **Branching:** A copy-on-write database branch per pull request, created in seconds rather than restored from a dump - **Compatibility:** Ordinary PostgreSQL wire protocol on port 5432 — Drizzle ORM 0.45 needs 0 code changes - **Watch for:** Cold starts after idle, and connection pooling being mandatory rather than optional - **Built with:** Neon Serverless PostgreSQL on port 5432, Drizzle ORM 0.45 unchanged, branches created by GitHub Actions, Next.js 16 preview deployments on Vercel, Playwright 1.59 run against each branch - **Numbers that matter:** Compute scales to 0 when idle; 1 branch per pull request; port 5432 unchanged; 2 things to plan for, cold starts and pooling - **Compare with:** Self-managed Postgres on AWS or Microsoft Azure, and MongoDB Atlas as a managed alternative - **Commonly paired with:** Drizzle ORM, Vercel deployments, GitHub Actions and Playwright preview tests - **Version horizon:** Upstream PostgreSQL supports majors 14 through 18; PostgreSQL 18 reaches end of life on 14 November 2030. A branch workflow inherits that date. - **Connection discipline:** A pooler in front, TypeScript 5.9 holding 1 connection per request, and Sentry alerting on pool exhaustion rather than on the port 5432 timeout it produces. - **Where it fits:** SaaS and Multi-tenant Architecture products on Vercel or AWS, where a Next.js 16 preview deployment needs its own database for the life of 1 pull request. ## Security & Access (8 terms) ### Immutable Audit Trail An Immutable Audit Trail is a security logging pattern that records all system events, database updates, and user accesses in an append-only, tamper-proof table that cannot be altered or deleted by any user or administrator. - **URL:** https://erpstack.io/glossary/audit-trail - **Markdown:** https://erpstack.io/glossary/audit-trail.md - **Rule:** Append only — 0 updates and 0 deletes; a correction is a new row referencing the old one - **Minimum fields:** 5: actor, action, entity, before/after state, and a UTC timestamp in ISO 8601 - **Transaction:** Written in the same PostgreSQL 18 transaction as the change, so the 2 cannot diverge - **Retention:** Sealed to WORM storage where a regulation requires the record to outlive the database - **Built with:** Append-only PostgreSQL 18 tables written through Drizzle ORM 0.45 in the same transaction as the change, sealed to AWS WORM storage by Terraform-defined policy, read paths gated by RBAC and SSO - **Numbers that matter:** 5 required fields; 0 updates and 0 deletes; 1 transaction covering both the change and its record; retention matched to the governing rule - **Compare with:** Application logs in Sentry, which are rotated, editable and not evidence - **Commonly paired with:** RBAC, SSO, Row-Level Security, WORM storage on AWS, Next.js 16 server actions, and SOC 2, ISO 27001 or GDPR reviews - **Where it is required:** healthcare, finance, government and aerospace records, where SOC 2, ISO 27001, HIPAA and FDA 21 CFR Part 11 Compliance reviewers all read the same PostgreSQL 18 table. ### Role-Based Access Control (RBAC) Role-Based Access Control (RBAC) is an authorization mechanism that restricts system access and database operations to authorized users based on their assigned organizational roles rather than individual user accounts. - **URL:** https://erpstack.io/glossary/rbac - **Markdown:** https://erpstack.io/glossary/rbac.md - **Model:** 3 layers: users hold roles, roles hold permissions, permissions gate operations - **Granularity:** Permission per operation, not per screen — 1 API route can be reached by 3 different interfaces - **Database pairing:** Row-Level Security in PostgreSQL 18 answers 'which rows', RBAC answers 'which actions' - **Audit expectation:** Every role change recorded, because reviewers test the 2 questions: who granted it and when - **Built with:** RBAC checks in Next.js 16 server actions, roles in PostgreSQL 18 via Drizzle ORM 0.45, input validated by Zod 4, SSO and JWT in front, Row-Level Security below, changes logged for SOC 2 - **Numbers that matter:** 3 layers — user, role, permission; 1 break-glass account used rarely; 2 audit questions, who granted it and when; 0 checks left in the interface only - **Compare with:** Per-user grants, and attribute-based schemes evaluated per request - **Commonly paired with:** SSO, JWT sessions, OAuth flows, Row-Level Security in PostgreSQL 18, Next.js 16 server actions and SOC 2 or ISO 27001 access reviews - **Role count:** 12 roles stays readable; 200 is the signal that the model needs scoping or attributes. Review the count each quarter beside the joiner-mover-leaver list. - **Where reviewers look:** healthcare, finance and government systems, where the role list and the Postgres grants underneath it have to tell the same story. ### JSON Web Token (JWT) A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact, self-contained way for securely transmitting information between parties as a JSON object, signed cryptographically. - **URL:** https://erpstack.io/glossary/jwt - **Markdown:** https://erpstack.io/glossary/jwt.md - **Specification:** RFC 7519, published May 2015 by the IETF - **Structure:** 3 base64url segments — header, payload, signature — separated by 2 dots - **Critical rule:** Verify the signature and reject 'alg: none'; the payload is encoded, not encrypted - **Lifetime:** Short-lived access tokens plus a revocable refresh token, because a signed token cannot be un-issued - **Built with:** JWT verification in Next.js 16 middleware, signing keys held in AWS, refresh tokens in PostgreSQL 18 or Redis, RBAC claims checked in server actions, failures reported to Sentry - **Numbers that matter:** RFC 7519, May 2015; 3 segments separated by 2 dots; 4 checks on every verify — signature, algorithm, expiry, audience; 0 secrets in the payload - **Compare with:** Server-side sessions in Redis or PostgreSQL 18, revocable immediately, or an OAuth introspection call per request - **Commonly paired with:** OAuth flows, SSO, RBAC claims, Redis or PostgreSQL 18 refresh storage, Next.js 16 middleware and Sentry on verification failures - **Claims to keep small:** A subject identifier, a tenant identifier and an expiry — not a profile. Claims are validated with Zod 4 on arrival and resolved against roles held in PostgreSQL 18 through Drizzle ORM 0.45. - **What reviewers sample:** Token lifetime, signing-key rotation and revocation at offboarding — the 3 items SOC 2 and ISO 27001 access reviews test across a Multi-tenant Architecture. ### Multi-Factor Authentication (MFA) Multi-Factor Authentication (MFA) is a security authentication process that requires a user to provide two or more verification factors to gain access to a resource, minimizing credential theft risk. - **URL:** https://erpstack.io/glossary/mfa - **Markdown:** https://erpstack.io/glossary/mfa.md - **Factor types:** 3 categories: something you know, something you have, something you are - **Strongest common form:** Phishing-resistant hardware or platform authenticators bound to 1 origin - **Weakest common form:** SMS codes — interceptable, and vulnerable to SIM reassignment - **Coverage gap:** Account recovery and 1 unprotected legacy login path defeat 100% of the control - **Built with:** MFA enforced at the identity provider in front of Next.js 16 applications on Vercel or AWS, sessions recorded in PostgreSQL 18, operator access through a Bastion Host, failures surfaced in Sentry - **Numbers that matter:** 3 factor categories, 2 required; 1 unprotected recovery path defeats 100% of the control; 0 knowledge-only pairs count as multi-factor - **Compare with:** Password-only sign-in, SSO without a second factor, or an OAuth flow with 0 phishing resistance in front of a Next.js 16 application - **Commonly paired with:** SSO at the identity provider, OAuth flows, JWT sessions, RBAC above them, a Bastion Host for operators, Next.js 16 middleware checks, and SOC 2, ISO 27001 or FedRAMP Security Controls evidence - **Coverage audit:** 4 paths to check — interactive login, API keys, help-desk reset, and legacy endpoints; 1 gap defeats 100% of the control - **Enforcement points:** SSO at the identity provider, JWT session claims, RBAC in Next.js 16 server actions, a Bastion Host for operator access and PostgreSQL 18 policies underneath — 5 places the second factor still has to hold. - **Where it is sampled:** healthcare, finance, government and retail estates working to SOC 2, ISO 27001, HIPAA or PCI DSS: 4 sectors, 4 frameworks, and 1 recovery path capable of undoing all of them. ### Zero-Trust Security Zero-Trust is a cybersecurity framework based on the premise that no user, device, or system should be trusted by default, whether inside or outside the organization's network perimeter. - **URL:** https://erpstack.io/glossary/zero-trust - **Markdown:** https://erpstack.io/glossary/zero-trust.md - **Principle:** Never trust, always verify — 0 implicit trust from network location - **Per request:** Identity, device posture and authorisation evaluated on each call, not once at the perimeter - **Reference framework:** NIST SP 800-53 Rev. 5, finalised 23 September 2020, is the control catalogue most assessments map to - **Blast radius:** Segmentation plus least privilege, so 1 compromised credential does not reach 100% of the estate - **Built with:** SSO and MFA at the edge, RBAC in Next.js 16, PostgreSQL 18 policies, Kubernetes segmentation and Terraform-defined AWS or Microsoft Azure networks, scanned with Semgrep SAST and OWASP ZAP - **Numbers that matter:** NIST SP 800-53 Rev. 5, 23 September 2020; 0 implicit trust from network position; 3 highest-value first steps; 1 identity per service, not 1 shared secret - **Compare with:** Perimeter security, where a Virtual Private Cloud boundary implies trust - **Commonly paired with:** SSO, MFA, JWT, RBAC, Terraform-defined AWS or Microsoft Azure networks, Kubernetes segmentation, Semgrep SAST and OWASP ZAP - **Reference architecture:** NIST SP 800-207, Zero Trust Architecture, published August 2020, is where the control language comes from; SP 800-53 Rev. 5 supplies the controls an assessment samples. - **Who asks for it:** government and finance buyers, and healthcare estates where a Virtual Private Cloud boundary on its own stopped counting as an answer. ### Bastion Host A Bastion Host is a special-purpose computer on a network specifically designed and configured to withstand attacks, serving as a secure gateway for administrators to access internal server networks. - **URL:** https://erpstack.io/glossary/bastion-host - **Markdown:** https://erpstack.io/glossary/bastion-host.md - **Role:** 1 hardened, audited entry point into a private subnet where databases have 0 public exposure - **Hardening:** Minimal packages, key-based authentication only, session recording, short-lived access grants - **Modern alternative:** Identity-aware session brokers that issue a 1-hour credential and record the session - **Failure mode:** A permanently running bastion with 12 standing accounts becomes the softest target in the estate - **Built with:** A hardened instance in an AWS Virtual Private Cloud defined by Terraform and applied through GitHub Actions, fronting PostgreSQL 18 and Kubernetes workloads, entry through SSO and MFA, sessions logged - **Numbers that matter:** 1 audited entry path; credentials expiring in 1 hour, not 1 year; 0 shared accounts; 2 things to forward, session capture and connection metadata - **Compare with:** A public database endpoint, an identity-aware broker issuing 1-hour credentials, or a Microsoft Azure equivalent - **Commonly paired with:** SSO and MFA at the door, RBAC for authorisation, Kubernetes and PostgreSQL 18 workloads behind it, Terraform on AWS or Microsoft Azure, GitHub Actions applying changes, and SOC 2 or ISO 27001 session evidence - **Standing access:** 0 permanent accounts; 1 request, 1 approval, 1 expiry per session, which is what SOC 2 and ISO 27001 reviewers sample - **What sits behind it:** Private-subnet workloads only: Postgres and Redis instances, Docker and Kubernetes nodes and the queue consumers beside them — 0 of which hold a public address. - **Who asks for one:** Assessors mapping to HIPAA, PCI DSS or FedRAMP Security Controls, and healthcare, finance or government buyers who sample 1 quarter of recorded sessions. ### Virtual Private Cloud (VPC) A Virtual Private Cloud (VPC) is an isolated private network carved out of a public cloud environment, allowing organizations to run servers and databases in a secure, custom network configuration. - **URL:** https://erpstack.io/glossary/vpc - **Markdown:** https://erpstack.io/glossary/vpc.md - **Structure:** 2 subnet tiers: public for load balancers, private for application and PostgreSQL 18 workloads - **Data tier rule:** 0 public IP addresses on database instances; reachable only from inside the network - **Controls:** Security groups for instance-level rules plus network ACLs at the subnet boundary - **Defined by:** Terraform, so the same topology is reproduced in 3 environments without hand-clicking - **Built with:** AWS networking defined in Terraform and applied by GitHub Actions, PostgreSQL 18 in private subnets, Kubernetes and Docker workloads beside it, Next.js 16 served through Vercel or a load balancer - **Numbers that matter:** 2 subnet tiers; 0 public IP addresses on the data tier; 3 environments from 1 definition; 1 NAT gateway for outbound-only access - **Compare with:** A flat network, public endpoints on AWS or Microsoft Azure managed services, or 1 shared network across 3 environments - **Commonly paired with:** A Bastion Host, Terraform and GitHub Actions provisioning, Docker and Kubernetes workloads, PostgreSQL 18 in the private tier, RBAC and SSO above it, and SOC 2, ISO 27001 or FedRAMP Security Controls network evidence - **Rule review:** 2 control layers, security groups and network ACLs; 3 environments each with 0 inbound paths to the data tier - **What lives in the private tier:** PostgreSQL 18 and Redis, Docker and Kubernetes nodes, and a Bastion Host as the 1 audited way in — every one of them with 0 public addresses. - **Who reads the diagram:** healthcare, finance and government assessors working to SOC 2, ISO 27001 or FedRAMP Security Controls, who sample the AWS or Microsoft Azure rules rather than the drawing. ### AWS Key Management Service (KMS) AWS Key Management Service (KMS) is a secure, managed service that makes it easy for developers to create and control cryptographic keys used to encrypt database columns, files, and server variables. - **URL:** https://erpstack.io/glossary/aws-kms - **Markdown:** https://erpstack.io/glossary/aws-kms.md - **Model:** Envelope encryption in 2 layers — 1 managed master key wraps the data keys that encrypt records - **Cipher:** AES-256 symmetric encryption for data keys; 0 master key material is ever exported - **Rotation:** Scheduled rotation without re-encrypting history, because earlier key versions stay available - **Audit value:** Every key use logged, which answers the 2 questions a reviewer asks: who decrypted what, and when - **Built with:** AWS key management wrapping AES-256 data keys used by PostgreSQL 18 columns, provisioned with Terraform, access gated by RBAC and SSO, key use logged and errors reported to Sentry - **Numbers that matter:** 2 encryption layers; AES-256 data keys; 0 master key material exported; 100% of key uses logged; 1 rotation that re-wraps rather than re-encrypts; 3 policies to review — key, role, and network - **Compare with:** Keys in environment variables, a Microsoft Azure key vault, or 1 shared secret in a Docker image - **Commonly paired with:** PCI DSS, HIPAA and ISO 27001 key controls, a Virtual Private Cloud boundary on AWS, Terraform provisioning, PostgreSQL 18 column encryption, WORM object storage, RBAC and SSO on key policies, and Sentry - **Audit questions:** 2 an assessor asks — who could decrypt, and who did; 100% of key operations logged outside the application boundary - **Rotation period:** Automatic AWS rotation defaults to a 365-day period; earlier key versions stay available, so 0 records are re-encrypted when it fires. - **What the keys protect:** PostgreSQL 18 columns, WORM objects on AWS, Redis snapshots and Docker secrets — 4 stores, 1 master key, 0 plaintext material outside the service. - **Who reads the policy:** 3 documents decide access: key policy, assuming role, network path. healthcare and finance assessors working to HIPAA or PCI DSS read all 3. ## Compliance & Regulation (11 terms) ### SOC 2 Compliance System and Organization Controls (SOC) 2 is a voluntary compliance standard for service organizations, developed by the AICPA, specifying how companies must manage customer data based on five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. - **URL:** https://erpstack.io/glossary/soc2 - **Markdown:** https://erpstack.io/glossary/soc2.md - **Framework:** AICPA Trust Services Criteria — 5 categories, of which only Security is mandatory - **Report types:** 2: Type I tests design at 1 point in time, Type II tests operation over a period - **Technical evidence:** Role-Based Access Control, immutable audit logs, encryption and change management - **Honest framing:** ERPStack holds 0 certifications; we build systems designed to be auditable against these criteria - **Built with:** RBAC and SSO on Next.js 16, PostgreSQL 18 audit tables through Drizzle ORM 0.45, infrastructure in Terraform, changes gated by GitHub Actions, Semgrep SAST scans, errors in Sentry - **Numbers that matter:** 5 Trust Services Criteria, 1 mandatory; 2 report types; ERPStack holds 0 certifications; Type II evidence produced continuously, not for 1 date - **Adjacent regimes:** ISO 27001, HIPAA, GDPR, PCI DSS and FedRAMP Security Controls - **Evidence toolchain:** SSO, RBAC, GitHub Actions change history, Semgrep SAST and Sentry ### HIPAA Compliance The Health Insurance Portability and Accountability Act (HIPAA) is a regulatory framework establishing national standards to protect sensitive patient health information (ePHI) from disclosure without consent. - **URL:** https://erpstack.io/glossary/hipaa - **Markdown:** https://erpstack.io/glossary/hipaa.md - **Statute:** Public Law 104-191 of 1996, extended by the HITECH Act, Public Law 111-5 of 2009 - **Rules in code:** 45 CFR Part 164, titled Security and Privacy, is the operative regulation - **Technical safeguards:** Access control, audit controls, integrity, authentication and transmission security - **Contractual step:** 1 Business Associate Agreement per vendor touching electronic protected health information - **Built with:** PostgreSQL 18 in an AWS private subnet defined by Terraform, AES-256 keys in a managed key service, RBAC, SSO and audit trails in Next.js 16, Sentry payloads scrubbed of ePHI - **Numbers that matter:** 45 CFR Part 164; Public Law 104-191 of 1996; HITECH is Public Law 111-5 of 2009; 1 Business Associate Agreement per vendor touching ePHI - **Adjacent regimes:** SOC 2, ISO 27001, GDPR and FDA 21 CFR Part 11 Compliance - **Commonly paired with:** FHIR interfaces, AWS key management, a Virtual Private Cloud boundary, Terraform provisioning, RBAC, SSO and an Immutable Audit Trail ### GDPR Data Compliance The General Data Protection Regulation (GDPR) is a comprehensive European Union regulation establishing strict guidelines for the collection, storage, and processing of personal data belonging to EU citizens. - **URL:** https://erpstack.io/glossary/gdpr - **Markdown:** https://erpstack.io/glossary/gdpr.md - **Instrument:** Regulation (EU) 2016/679, adopted 27 April 2016 and applicable from 25 May 2018 - **Breach notification:** Article 33 — the supervisory authority told without undue delay and within 72 hours where feasible - **Subject request:** Article 12(3) — answered within 1 month, extendable by 2 further months - **Upper fine tier:** Article 83(5) — up to 20 000 000 EUR or 4 % of total worldwide annual turnover - **Built with:** Subject-identity mapping in PostgreSQL 18 via Drizzle ORM 0.45, export and erasure paths in Next.js 16, RBAC and SSO over them, Sentry payloads scrubbed, backups on AWS covered by policy - **Numbers that matter:** Regulation (EU) 2016/679 of 27 April 2016; applicable 25 May 2018; 72 hours to notify; 1 month to answer; up to 20 000 000 EUR or 4 % of turnover - **Adjacent regimes:** SOC 2, ISO 27001, HIPAA and FERPA Education Compliance - **Commonly paired with:** A CRM subject-request path, Row-Level Security and RBAC over PostgreSQL 18, SSO on operator access, Drizzle ORM 0.45 deletion paths, Sentry payload scrubbing, ClickHouse extract coverage and WORM retention rules - **Systems in scope:** The ERP on PostgreSQL 18, a CRM, ClickHouse extracts, MongoDB Atlas collections, Redis caches, Sentry payloads and AWS backups — 7 surfaces, 1 subject identifier. - **Who feels it first:** healthcare, finance, insurance and retail estates, plus any SaaS processor acting for a controller inside the European Union. ### FERPA Education Compliance The Family Educational Rights and Privacy Act (FERPA) is a federal law in the United States that protects the privacy of student education records, restricting access to authorized school officials. - **URL:** https://erpstack.io/glossary/ferpa - **Markdown:** https://erpstack.io/glossary/ferpa.md - **Statute:** 20 U.S.C. 1232g, implemented by 34 CFR Part 99, Family Educational Rights and Privacy - **Protected object:** Education records — 1 student's records, wherever the institution stores them - **Core rights:** Inspect, request amendment, and control disclosure of personally identifiable information - **Engineering shape:** Consent state per disclosure, plus an audit trail of every record access - **Built with:** Read-and-write audit logging in PostgreSQL 18 through Drizzle ORM 0.45, consent state per disclosure, RBAC and SSO enforced by Next.js 16, hosted on AWS with Sentry scrubbed of student data - **Numbers that matter:** 20 U.S.C. 1232g, implemented by 34 CFR Part 99; source at 53 FR 11943, 11 April 1988; 3 core rights — inspect, amend, control disclosure - **Adjacent regimes:** GDPR obligations over the same records, and SOC 2 or ISO 27001 controls covering the institution's systems - **Commonly paired with:** SSO, RBAC, Row-Level Security in PostgreSQL 18, read-level audit logging, Next.js 16 server actions and SOC 2 or ISO 27001 controls - **Access path:** SSO with OAuth 2.0 at the identity provider, RBAC over Next.js 16 server actions, and every read written to Postgres — the read log is what a FERPA review samples. - **Who holds the records:** edtech vendors first, then the government agencies and healthcare units inside a university that hold the same student under a different rule. ### PCI-DSS Financial Compliance The Payment Card Industry Data Security Standard (PCI-DSS) is a set of security standards designed to ensure that all companies that accept, process, store or transmit credit card information maintain a secure environment. - **URL:** https://erpstack.io/glossary/pci-dss - **Markdown:** https://erpstack.io/glossary/pci-dss.md - **Standard:** PCI DSS v4.x, maintained by the PCI Security Standards Council - **Scope rule:** 100% of systems that store, process or transmit cardholder data fall inside the boundary - **Cheapest strategy:** Reduce scope to 0 stored card numbers using 1 tokenising payment provider - **Never store:** Sensitive authentication data after authorisation — including the 3-digit security code - **Key handling:** AES-256 encryption with keys held in a managed key service, rotated on a defined schedule - **Built with:** A tokenising provider in front of Next.js 16, 0 card numbers in PostgreSQL 18, AES-256 keys in AWS provisioned by Terraform, RBAC and SSO over admin paths, Sentry payloads scrubbed - **Numbers that matter:** PCI DSS v4.x; 0 stored card numbers is the cheapest scope; the 3-digit code must never be retained; AES-256 for anything that remains - **Adjacent regimes:** SOC 2, ISO 27001 and GDPR for the personal data alongside payments - **Commonly paired with:** AWS key management, a Virtual Private Cloud boundary, RBAC, SSO, Terraform provisioning, Semgrep SAST and OWASP ZAP scanning - **Scope arithmetic:** 1 tokenising provider removes the card number from your systems: 0 primary account numbers at rest, 0 retention of the 3-digit code after authorisation, and a token that is useless if exfiltrated. - **Clocks running beside it:** GDPR Article 33 gives 72 hours to report a breach of the personal data sitting next to the payment, and Article 12(3) gives 1 month to answer the cardholder asking what you hold. - **Surfaces to prove clean:** The ERP on PostgreSQL 18, a CRM holding the customer, Redis caches, a ClickHouse analytics database extract, Sentry payloads and AWS backups — 6 places that each have to show 0 stored card numbers. ### FISMA Government Compliance The Federal Information Security Modernization Act (FISMA) is a United States federal law that defines a comprehensive framework to protect government information, operations, and assets against natural or man-made threats. - **URL:** https://erpstack.io/glossary/fisma - **Markdown:** https://erpstack.io/glossary/fisma.md - **Control catalogue:** NIST SP 800-53 Rev. 5, finalised 23 September 2020 - **Categorisation:** 3 impact levels — low, moderate and high — driving how many controls apply - **Process:** Categorise, select, implement, assess, authorise, monitor — 6 steps, continuously repeated - **Evidence:** Continuous monitoring, not an annual snapshot, is what the authorisation depends on - **Built with:** Terraform-defined AWS or Microsoft Azure infrastructure, GitHub Actions change control, Kubernetes workloads, centralised logging, Semgrep SAST and OWASP ZAP scans, Sentry for errors - **Numbers that matter:** NIST SP 800-53 Rev. 5, 23 September 2020; 3 impact levels; 6 process steps repeated continuously; 1 categorisation decision that sets everything else - **Adjacent regimes:** FedRAMP Security Controls, SOC 2 and ISO 27001 in commercial contexts - **Commonly paired with:** Terraform, GitHub Actions, Docker and Kubernetes workloads, Semgrep SAST, OWASP ZAP, RBAC, SSO and centralised logging ### FedRAMP Security Controls The Federal Risk and Authorization Management Program (FedRAMP) is a US government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. - **URL:** https://erpstack.io/glossary/fedramp - **Markdown:** https://erpstack.io/glossary/fedramp.md - **Basis:** NIST SP 800-53 Rev. 5 controls, finalised 23 September 2020, applied to cloud services - **Baselines:** 3 impact baselines — low, moderate and high — with control counts rising accordingly - **Reuse model:** 1 authorisation package, many agencies — the point is to avoid N separate assessments - **Practical constraint:** Your service inherits controls only from cloud services already authorised at your baseline - **Built with:** Workloads on AWS or Microsoft Azure defined in Terraform, RBAC and SSO in Next.js 16, PostgreSQL 18 encrypted at rest, changes gated by GitHub Actions, monitored through Sentry - **Numbers that matter:** 3 baselines from NIST SP 800-53 Rev. 5; 1 authorisation package reused by N agencies; ERPStack holds 0 authorisations; 0 controls inherited from unauthorised infrastructure - **Adjacent regimes:** FISMA Government Compliance, SOC 2 and ISO 27001 - **Commonly paired with:** AWS or Microsoft Azure authorised services, Terraform, GitHub Actions change control, Docker workloads, RBAC, SSO and Sentry monitoring - **Who it applies to:** government agencies buying a cloud service. Adjacent healthcare and finance estates reuse the same NIST SP 800-53 Rev. 5 control language without the authorisation. ### AS9100 Aerospace Standard AS9100 is a widely adopted and standardized quality management system (QMS) for the aerospace industry, incorporating ISO 9001 requirements alongside aerospace-specific quality and safety criteria. - **URL:** https://erpstack.io/glossary/as9100 - **Markdown:** https://erpstack.io/glossary/as9100.md - **Basis:** The ISO 9001 quality management system plus aviation, space and defence requirements - **Software implication:** Traceability from 1 delivered serial number back through its parts, revisions and inspections - **Records:** Append-only history with 0 in-place edits, so a build from 10 years ago still reconstructs - **Key artefacts:** 3 recurring ones: Bill of Materials revisions, nonconformance records, first-article results - **Certification:** Awarded to an organisation by an accredited body — ERPStack holds 0 certifications - **Built with:** Traceability tables in PostgreSQL 18 through Drizzle ORM 0.45, surfaced in a Next.js 16 and React 19 ERP, revisions sealed to AWS WORM storage, approvals gated by RBAC and SSO - **Numbers that matter:** 1 serial number traced to N part lots; ISO 9001 as the base; 0 in-place edits to quality records; 3 artefacts an auditor samples first - **Adjacent standards:** ISO 27001 for information security, and FDA 21 CFR Part 11 Compliance in regulated production - **Commonly paired with:** Bill of Materials revisions, an ERP work order, WORM storage and RBAC approvals - **Sectors that require it:** aerospace primes and the manufacturing and logistics suppliers feeding them, with ISO 27001 and FDA 21 CFR Part 11 Compliance adjacent in defence and regulated production. ### FDA 21 CFR Part 11 Compliance FDA 21 CFR Part 11 is a United States Food and Drug Administration regulation establishing criteria under which electronic records and electronic signatures are considered trustworthy and equivalent to paper records. - **URL:** https://erpstack.io/glossary/fda-part-11 - **Markdown:** https://erpstack.io/glossary/fda-part-11.md - **Regulation:** 21 CFR Part 11, Electronic Records; Electronic Signatures, published at 62 FR 13464 on 20 March 1997 - **Authority:** 21 U.S.C. 321-393 and 42 U.S.C. 262, as recorded in the Code of Federal Regulations - **Core demands:** Validated systems, secure audit trails, record retention and controlled electronic signatures - **Signature rule:** Each signature linked to its record so it cannot be transplanted onto another one - **Built with:** Append-only PostgreSQL 18 records through Drizzle ORM 0.45, signature binding in Next.js 16, WORM storage on AWS, validation evidence from Vitest 4 and Playwright 1.59 in GitHub Actions - **Numbers that matter:** 21 CFR Part 11; 62 FR 13464, 20 March 1997; authority 21 U.S.C. 321-393 and 42 U.S.C. 262; audit trails retained at least as long as the record - **Adjacent regimes:** HIPAA, SOC 2, ISO 27001 and AS9100 Aerospace Standard in regulated manufacturing - **Commonly paired with:** WORM storage on AWS, an Immutable Audit Trail in PostgreSQL 18, RBAC and SSO on signing, Certified Timesheet Tracking, Drizzle ORM 0.45 append-only writes, and Vitest 4 and Playwright 1.59 validation evidence - **Sectors it governs:** biotech and healthcare manufacturers, plus the manufacturing and logistics systems feeding them — all reading 1 audit trail in PostgreSQL 18 under RBAC and SSO. ### FHIR (Fast Healthcare Interoperability Resources) FHIR (Fast Healthcare Interoperability Resources) is a standard for healthcare data exchange developed by HL7 International, defining a set of REST APIs and JSON/XML data formats for electronic health records (EHR) interoperability. - **URL:** https://erpstack.io/glossary/fhir - **Markdown:** https://erpstack.io/glossary/fhir.md - **Current release:** FHIR R5, published by HL7 as version 5.0.0; R4 and R4B remain widely deployed - **Model:** Modular resources — Patient, Observation, Encounter — exchanged over 1 RESTful API - **Format:** 2 interchangeable wire formats, JSON and XML, over the same resource definitions - **Extension mechanism:** Profiles constrain resources for 1 use case without forking the base specification - **Integration reality:** Target the counterpart's version — R4 is still the common denominator in production estates - **Built with:** Next.js 16 API routes mapping FHIR resources to PostgreSQL 18 tables through Drizzle ORM 0.45, payloads validated with Zod 4, RBAC and SSO enforced, hosted on AWS with an Immutable Audit Trail - **Numbers that matter:** R5 is version 5.0.0; R4 remains the common denominator; 2 wire formats, JSON and XML; 3 core resources — Patient, Observation, Encounter - **Adjacent standards:** HIPAA safeguards, SOC 2 controls and ISO 27001 information security - **Commonly paired with:** REST clients, a PostgreSQL Database, RBAC, SSO and an Immutable Audit Trail - **Version arithmetic:** R5 is 5.0.0, R4B is 4.3.0 (May 2022) and R4 is 4.0.1 (October 2019). An integration targets 1 of the 3; translating between them is a project, not a configuration setting. - **Where it lands:** healthcare and biotech estates mapping resources into PostgreSQL 18 through Drizzle ORM 0.45, validated with Zod 4, with RBAC, SSO and an Immutable Audit Trail over every read. ### Data Subject Access Request (DSAR) A Data Subject Access Request (DSAR) is a legal right granted to individuals under GDPR, CCPA, and equivalent privacy laws to request that an organization provide, correct, or delete all personal data held about them within a statutory deadline — 1 month under GDPR Article 12(3), 45 days under California Civil Code 1798.130. - **URL:** https://erpstack.io/glossary/dsar - **Markdown:** https://erpstack.io/glossary/dsar.md - **Legal clock:** GDPR Article 12(3) — 1 month to respond, extendable by 2 further months where justified - **Scope problem:** 1 person may exist across many tables, backups, logs and third-party processors - **Engineering answer:** A subject-identity index so the search is 1 query rather than a manual hunt - **Conflict to resolve:** Erasure requests against WORM records a separate regulation requires you to retain - **Built with:** 1 subject identifier referenced by every personal-data table in PostgreSQL 18, exports built in Next.js 16 with Drizzle ORM 0.45, RBAC and SSO gating the operator, Sentry payloads scrubbed - **Numbers that matter:** Article 12(3): 1 month, extendable by 2; 1 query instead of a hunt across 20 tables; 4 places data hides — tables, extracts, logs, backups - **Where the data hides:** A CRM, the ERP on PostgreSQL 18, ClickHouse extracts, MongoDB Atlas collections, Redis caches, Sentry payloads and AWS backups - **Commonly paired with:** Row-Level Security and RBAC over PostgreSQL 18, SSO on the operator path, an Immutable Audit Trail, Drizzle ORM 0.45 export queries, Sentry payload scrubbing, ClickHouse extract coverage and documented AWS backup retention - **Coverage checklist:** 6 surfaces to cover — PostgreSQL 18 tables, ClickHouse extracts, Sentry payloads, AWS backups, a CRM, and any processor acting for you - **Two statutory clocks:** GDPR Article 12(3) gives 1 month, extendable by 2 further months. California Civil Code 1798.130 gives 45 days, extendable once by another 45 with notice inside the first period. - **Who receives them:** retail and healthcare records first, then finance, insurance and legaltech files held under a separate retention rule. - **Processors that answer too:** Every SaaS acting for you — a CRM, Monday.com Work OS boards, Zoho Creator apps, HubSpot lists — runs on the same clock as the ERP on PostgreSQL 18. ## Cloud & Delivery (12 terms) ### Cloud Migration Cloud migration is the strategic process of moving an organization's digital assets, legacy database systems, servers, and business applications from on-premises hardware or legacy datacenters into a modern cloud hosting infrastructure. - **URL:** https://erpstack.io/glossary/cloud-migration - **Markdown:** https://erpstack.io/glossary/cloud-migration.md - **Strategies:** Rehost, replatform, refactor, repurchase, retire, retain — 6 options, rarely just 1 - **Sequencing:** Move 1 workload at a time behind a routing facade, not 100% in a single weekend - **Target shape:** Private subnets in a Virtual Private Cloud, defined in Terraform, with 0 public database endpoints - **Cost trap:** Lift-and-shift of an always-on fleet, which reproduces on-premise spend with 2 bills instead of 1 - **Built with:** AWS, Microsoft Azure or Vercel targets defined in Terraform, Docker and Kubernetes for portability, PostgreSQL 18 as the destination store, cutover run through GitHub Actions with Sentry watching - **Numbers that matter:** 6 strategies; 1 workload at a time; 2 bills during transition; 3 things to fix first — hostnames, shared file systems, credentials in config - **Target platforms:** AWS, Microsoft Azure and Vercel, with Docker or Kubernetes for portable workloads - **Commonly paired with:** Terraform, GitHub Actions, the Strangler Fig Migration Pattern, Docker and Kubernetes portability, PostgreSQL 18 replication, Sentry and FinOps cost tracking - **Cutover mechanics:** Logical replication from the legacy PostgreSQL database into the target, Redis warmed before the window, and Edge Caching / CDN in front of static assets; DNS time-to-live dropped to 60 seconds at least 24 hours ahead so a rollback propagates in 1 minute. - **Hardest estates:** Regulated workloads in healthcare, finance and government, where day 1 on the new platform has to produce the evidence day 0 produced. Keep the source system readable for 30 days after cutover rather than 0. ### Technical Debt Technical debt is the implied cost of future software refactoring and debugging caused by choosing a fast, temporary code solution now instead of a well-architected, flexible long-term approach. - **URL:** https://erpstack.io/glossary/tech-debt - **Markdown:** https://erpstack.io/glossary/tech-debt.md - **Definition:** The gap between the design you have and the design the problem now needs - **Deliberate vs accidental:** 2 kinds — a conscious shortcut with a repayment plan, or drift nobody chose - **Measurable signals:** Change lead time, test coverage on hot paths, and count of dependencies more than 2 majors behind - **Interest:** Paid on every future change, which is why 1 untouched module can carry debt cheaply for years - **Built with:** TypeScript 5.9 typed contracts, Vitest 4, Playwright 1.59 and Storybook in GitHub Actions, Semgrep SAST and OWASP ZAP scanning, dependencies on Next.js 16 and React 19 updated continuously - **Numbers that matter:** Dependencies more than 2 majors behind are a signal; interest is paid on 100% of future changes; 4 proxies to track, none perfect on its own - **Where it accumulates:** Untested Node.js services, unpinned dependencies and forked SaaS customisations - **Countered by:** Vitest 4, Playwright 1.59, Storybook, Semgrep SAST, OWASP ZAP, GitHub Actions, TypeScript 5.9 contracts and Sentry regression alerts - **Currency as a measure:** The versions pinned in this repository are Next.js 16, React 19, Drizzle ORM 0.45, TypeScript 5.9 and Zod 4. Anything more than 2 majors behind is the first debt to price. ### Edge Caching / CDN Edge Caching is the practice of storing static files, API JSON payloads, and pre-rendered HTML pages on servers located close to the user (at the 'edge' of the network) to reduce latency and speed up page load times. - **URL:** https://erpstack.io/glossary/edge-caching - **Markdown:** https://erpstack.io/glossary/edge-caching.md - **Mechanism:** Responses served from a location near the user instead of 1 origin thousands of kilometres away - **Control:** Cache-Control and stale-while-revalidate headers, defined in RFC 9111 for HTTP caching - **Invalidation:** Tag-based purging so publishing 1 record clears 2 routes rather than the whole site - **Never cache:** Authenticated or tenant-scoped responses without a key that includes the tenant identity - **Built with:** Vercel edge caching in front of Next.js 16 and React 19, cache tags invalidated when Payload CMS content in PostgreSQL 18 changes, Redis at the origin, Sentry watching hit rates - **Numbers that matter:** RFC 9111 defines HTTP caching; publishing 1 record clears 2 routes; 0 shared caching of tenant-scoped responses; seconds of staleness, not hours - **Compare with:** Origin-only serving, Redis caching inside 1 region, or a CDN with 0 tag-based invalidation - **Commonly paired with:** Next.js 16 and React 19 rendering, a Headless CMS with Payload CMS content in PostgreSQL 18, Redis at the origin, Vercel or AWS hosting, Terraform configuration, Tailwind CSS 4 assets and Sentry monitoring - **Safety rule:** 0 shared caching of authenticated responses; tenant identity in the cache key or Cache-Control set to private, with 2 layers never sharing 1 key - **What is cached where:** Next.js 16 and React 19 output on Vercel or AWS, Payload CMS content from PostgreSQL 18 behind a Headless CMS, Tailwind CSS 4 assets at the edge and Redis at the origin. - **Who notices:** retail, media and hospitality traffic, where a 3-second first load and a 300-millisecond one are different conversion rates on the same page. ### Incremental Static Regeneration (ISR) Incremental Static Regeneration (ISR) is a Next.js rendering pattern that allows developers to update static pages in the background after site deployment without rebuilding the entire website. - **URL:** https://erpstack.io/glossary/isr - **Markdown:** https://erpstack.io/glossary/isr.md - **What it solves:** Static speed with fresh data, without rebuilding 10,000 pages to change 1 - **Mechanism:** Serve the cached page, regenerate in the background, replace it for the next request - **Invalidation:** Cache tags, so publishing 1 record revalidates the 2 or 3 routes that show it - **Framework:** Next.js 16 with React 19, the versions this site itself runs on - **Built with:** Next.js 16 and React 19 with cache tags and Tailwind CSS 4, content from Payload CMS on PostgreSQL 18 via Drizzle ORM 0.45, built by GitHub Actions in TypeScript 5.9, served from Vercel or AWS, errors in Sentry - **Numbers that matter:** 1 route regenerated instead of 10,000 rebuilt; 0 users waiting for regeneration; seconds of staleness; 2 or 3 routes touched per publish - **Compare with:** Full static generation, server rendering every request, client-side fetching in React 19 against a REST API, or Redis-cached HTML behind Docker - **Commonly paired with:** Payload CMS on PostgreSQL 18, a Headless CMS content model, Edge Caching / CDN on Vercel, Redis at the origin, Next.js 16 and React 19 rendering, Tailwind CSS 4 styling and Sentry monitoring - **Cache-tag design:** 1 tag per record plus 1 per index route; publishing 1 article revalidates 2 or 3 routes rather than all 10,000 - **Caching layers around it:** Edge Caching / CDN on Vercel in front, Redis at the origin, Payload CMS content in PostgreSQL 18 behind, and Next.js 16 cache tags tying the 3 together. ### GraphQL API Schema GraphQL is a query language for APIs that allows client applications to request precisely the data fields they need, reducing over-fetching and consolidating multiple database requests into a single network call. - **URL:** https://erpstack.io/glossary/graphql - **Markdown:** https://erpstack.io/glossary/graphql.md - **Model:** 1 endpoint, 1 typed schema; the client states exactly which fields it needs - **Strength:** Collapses 4 REST round trips into 1 request shaped for the screen - **Cost:** Caching is harder than REST, and 1 badly shaped query can trigger an N+1 storm - **Mitigations:** Query depth and complexity limits, persisted queries, and batching at the resolver layer - **Built with:** A GraphQL schema over Drizzle ORM 0.45 and PostgreSQL 18, served from Next.js 16, types shared through TypeScript 5.9, Redis caching resolvers, traced with OpenTelemetry - **Numbers that matter:** 1 endpoint, 1 schema; 4 REST round trips collapsed into 1; 50 orders can become 51 queries without batching; 3 guards — depth, complexity, persisted queries - **Compare with:** REST resources, or tRPC Protocol procedures inside 1 TypeScript codebase - **Commonly paired with:** Redis caching, Drizzle ORM 0.45 resolvers, Zod 4 validation, Next.js 16 routes, Apache Kafka subscriptions and Sentry tracing ### tRPC Protocol tRPC is a protocol that allows developers to build end-to-end type-safe APIs without code generation by sharing TypeScript type definitions between the backend server and frontend client. - **URL:** https://erpstack.io/glossary/trpc - **Markdown:** https://erpstack.io/glossary/trpc.md - **Model:** Typed remote procedure calls where 1 TypeScript 5.9 type definition serves client and server - **Code generation:** None — types are inferred, so there is 0 build step keeping 2 artefacts in sync - **Boundary:** Works when both ends share a repository; use REST or GraphQL for consumers you do not own - **Validation:** Zod 4 schemas at the procedure boundary, because types vanish at runtime - **Built with:** tRPC procedures in a Next.js 16 application, TypeScript 5.9 inference, Zod 4 validation, Drizzle ORM 0.45 over PostgreSQL 18, covered by Vitest 4 and Playwright 1.59 - **Numbers that matter:** 1 type definition serving both ends; 0 code generation; 2 layers still needed, TypeScript 5.9 types and Zod 4 runtime validation - **Compare with:** REST endpoints, a GraphQL API Schema, or Next.js server actions - **Commonly paired with:** Zod, Drizzle ORM, React clients, Vitest and Playwright coverage - **Where it fits:** Internal B2B Software and SaaS products where 1 repository holds a Next.js 16 front end, Drizzle ORM 0.45 over PostgreSQL 18, and Vitest 4 and Playwright 1.59 covering both ends. ### Progressive Web Application (PWA) A Progressive Web Application (PWA) is a type of application software delivered through the web, built using common web technologies including HTML, CSS, and JavaScript, designed to work on any platform. - **URL:** https://erpstack.io/glossary/pwa - **Markdown:** https://erpstack.io/glossary/pwa.md - **Requirements:** 3 pieces: HTTPS, a web app manifest, and a service worker controlling the cache - **Offline model:** Queue writes locally, replay when connectivity returns — every replay must be idempotent - **Distribution:** 1 URL, 0 app store review cycles, updates delivered on next load - **Best fit:** Warehouse scanners, field service and shop-floor terminals on unreliable networks - **Built with:** Next.js 16 and React 19 with a service worker and Tailwind CSS 4, writes queued locally and replayed into PostgreSQL 18 through Drizzle ORM 0.45, hosted on Vercel or AWS with Sentry reporting - **Numbers that matter:** 3 requirements — HTTPS, manifest, service worker; 1 URL instead of 2 app store submissions; 0 review cycles; 1 idempotency key per queued write - **Compare with:** A native app, a plain React 19 web application with no service worker, or an Electron desktop build talking to the same REST API - **Commonly paired with:** Edge Caching / CDN in front of Next.js 16 and React 19, Idempotency in API Design on replay, PostgreSQL 18 and Redis behind the API, Tailwind CSS 4 for the shell, Vercel or AWS hosting, Playwright 1.59 offline tests and Sentry - **Offline write path:** 1 local queue, 1 idempotency key per write, replayed against PostgreSQL 18; Redis absorbs the burst when 50 devices reconnect at once - **Field hardware:** Warehouse scanners and shop-floor terminals in logistics, manufacturing and retail, served by Next.js 16 and React 19 through Edge Caching / CDN with Tailwind CSS 4 in the shell. - **Sync path:** Queued writes replay into PostgreSQL 18 through Drizzle ORM 0.45 with Idempotency in API Design on every key, Redis absorbing the burst, Sentry reporting a replay that fails twice. ### CI/CD Deployment Pipelines CI/CD (Continuous Integration and Continuous Delivery) is a set of practices and tools that automates the building, testing, and deployment of software changes to staging and production environments. - **URL:** https://erpstack.io/glossary/ci-cd - **Markdown:** https://erpstack.io/glossary/ci-cd.md - **Pipeline stages:** 5 gates on every pull request: typecheck, lint, unit tests, end-to-end tests, build - **Tooling:** GitHub Actions running Vitest 4 and Playwright 1.59 against a preview database branch - **Release control:** Deploy continuously, release behind feature flags — 2 separate decisions - **Rollback:** 1 previous immutable build kept ready, so recovery is a switch rather than a rebuild - **Built with:** GitHub Actions running TypeScript 5.9 typecheck, lint, Vitest 4 and Playwright 1.59, building Docker images, deploying to Vercel, AWS or Kubernetes, with Sentry releases tagged per deploy - **Numbers that matter:** 5 gates per pull request; minutes not hours; 1 previous build retained for rollback; 2 migration phases, expand then contract - **Toolchain:** GitHub Actions, Docker images, Vitest, Playwright, Semgrep SAST and OWASP ZAP - **Deploy targets:** GitHub Actions, Docker images, Vitest 4, Playwright 1.59, Semgrep SAST, OWASP ZAP, Vercel or AWS deploys, Kubernetes rollouts and Sentry releases - **Migration safety:** Two-phase schema change: expand, deploy, backfill, contract — 4 steps, so 1 rollback never meets a column that has already been dropped. - **Where the log is evidence:** healthcare, finance and government delivery, where the pipeline record is the change-control artefact an assessor reads instead of a ticket. - **Why duration matters:** 5 gates finishing in 8 minutes get run on every push; the same 5 taking 45 minutes get worked around. 1 previous immutable build stays ready for a 1-step rollback. ### Infrastructure as Code (IaC) Infrastructure as Code (IaC) is the practice of managing and provisioning computer cloud infrastructure—such as virtual servers, networks, and databases—using machine-readable definition files. - **URL:** https://erpstack.io/glossary/iac - **Markdown:** https://erpstack.io/glossary/iac.md - **Principle:** The repository is the source of truth; a console change is drift to be corrected, not a fix - **Tooling:** Terraform definitions reviewed in pull requests and applied by GitHub Actions - **Payoff:** 3 environments reproduced from 1 definition, differing only by variables - **Disaster recovery:** Rebuilding a region becomes an apply, not an archaeology exercise across 40 console screens - **Built with:** Terraform definitions reviewed in pull requests and applied by GitHub Actions against AWS or Microsoft Azure, provisioning a Virtual Private Cloud, Kubernetes clusters, PostgreSQL 18 and a Bastion Host - **Numbers that matter:** 3 environments from 1 definition; 0 undocumented console changes; rebuilding a region becomes 1 apply instead of 40 screens - **Compare with:** Console clicks on AWS or Microsoft Azure, Docker Compose files describing 1 machine and no network, or a Vercel project configured entirely in a dashboard - **Commonly paired with:** Docker and Kubernetes workloads, GitHub Actions applying plans, a Bastion Host and Virtual Private Cloud on AWS or Microsoft Azure, PostgreSQL 18 provisioning, RBAC and SSO, and SOC 2 or ISO 27001 change evidence - **Drift control:** 1 source of truth; an emergency console change is reconciled within 1 working day, not left for 6 months - **State discipline:** 1 remote state per environment with locking, so a second concurrent apply is refused rather than merged; Postgres rules are never edited outside the plan. - **Who reads the plan:** government, finance and energy estates on AWS or Microsoft Azure, where Terraform plans, Kubernetes manifests and Docker images are the only description of production SOC 2 and ISO 27001 assessors accept. ### Sentry Observability Platform Sentry is an open-source application monitoring and error tracking platform that helps developers identify, diagnose, and resolve application bugs and database performance bottlenecks in real time. - **URL:** https://erpstack.io/glossary/sentry - **Markdown:** https://erpstack.io/glossary/sentry.md - **Primary job:** Group thousands of raw exceptions into a handful of distinct issues with stack traces - **Release context:** Errors tied to a release and commit, so 1 deploy can be identified as the cause - **Source maps:** Uploaded at build time, so a minified browser stack trace maps back to real source lines - **Privacy duty:** Scrub personal data before sending — an error payload can otherwise carry 2 kinds of regulated data - **Built with:** Sentry wired into Next.js 16, React 19 and Node.js services, source maps uploaded by GitHub Actions at build time, releases tagged per Vercel or AWS deploy, traces joined to OpenTelemetry, TypeScript 5.9 throughout - **Numbers that matter:** Thousands of events grouped into a handful of issues; 1 release identifier per deploy; 0 personal data sent; 6 months of unscrubbed payloads is the classic incident; 2 signals to join, exceptions and traces - **Compare with:** Raw Node.js logs, or OpenTelemetry Observability traces without exception grouping - **Commonly paired with:** Next.js 16, React 19, Node.js services, GitHub Actions releases, Playwright 1.59 runs, OpenTelemetry Observability traces and GDPR scrubbing rules - **Sampling arithmetic:** Errors captured at 100%, traces sampled: a 10% trace rate on a service taking 1,000,000 requests a day still leaves 100,000 traces to search. - **Why scrubbing is urgent:** GDPR Article 33 allows 72 hours to notify a supervisory authority. An error payload that carried personal data for 6 months is a breach report, not a debugging convenience. - **Where it runs:** 1 SDK across Next.js 16, React 19 and Node.js services on Docker, Kubernetes, AWS or Vercel, with 1 GitHub Actions step uploading source maps and 3 signals to join — exception, trace, release. ### OpenTelemetry Observability OpenTelemetry (OTel) is an open-source observability framework for collecting, processing, and exporting telemetry data — traces, metrics, and logs — from distributed applications into monitoring backends like Grafana, Datadog, or Jaeger. - **URL:** https://erpstack.io/glossary/opentelemetry - **Markdown:** https://erpstack.io/glossary/opentelemetry.md - **Signals:** 3: traces, metrics and logs, emitted through 1 vendor-neutral instrumentation API - **Trace model:** 1 trace identifier propagated across every hop, so a request is reconstructable end to end - **Portability:** Instrument once, change backend later — the code does not know which vendor receives the data - **Cost control:** Sampling, because retaining 100% of traces at volume costs more than the insight is worth - **Built with:** OpenTelemetry instrumentation in Next.js 16 and TypeScript 5.9 services on Docker and Kubernetes, spans covering PostgreSQL 18 queries, Redis calls and Apache Kafka hops, joined to Sentry - **Numbers that matter:** 3 signals; 1 trace identifier across every hop; keep 100% of errors and sample the rest; 6 services in 1 request is common - **Compare with:** Vendor-specific agents, or Sentry alone for exception grouping - **Commonly paired with:** Sentry error grouping, Docker and Kubernetes workloads, Apache Kafka consumers, Next.js 16 server code, Redis calls and PostgreSQL 18 queries ### FinOps (Cloud Financial Operations) FinOps is a cloud financial management practice that enables organizations to maximize business value by collaborating on cloud cost data, tracking resource utilization, and optimizing infrastructure spend in real time. - **URL:** https://erpstack.io/glossary/finops - **Markdown:** https://erpstack.io/glossary/finops.md - **Practice:** 3 phases repeated continuously: inform, optimise, operate - **Attribution:** Tag every resource to a team or product, or 100% of spend lands in 1 unallocated bucket - **Biggest lever:** Turning non-production environments off outside working hours, and right-sizing what remains - **Unit metric:** Cost per tenant or per transaction, which is the only figure that scales meaningfully - **Built with:** Terraform-tagged AWS, Microsoft Azure and Vercel resources, Kubernetes requests right-sized, Neon Serverless PostgreSQL scaled to 0 off-hours, usage tracked per tenant in PostgreSQL 18 - **Numbers that matter:** 3 repeating phases; 24 hours of runtime for an 8-hour working day is the classic waste; 100% tagging or nothing; 1 unit metric, cost per tenant - **Where spend accumulates:** An untagged bill, reserved-capacity purchases, or Docker hosts left running at 100% of the week - **Commonly paired with:** Terraform tagging across AWS, Microsoft Azure and Vercel, Neon Serverless PostgreSQL scaled to 0, Kubernetes and Docker right-sizing, ClickHouse retention policy, Multi-tenant Architecture unit costs, and OpenTelemetry Observability sampling - **Where it leaks:** 3 usual leaks — 24-hour non-production runtime, ClickHouse retention nobody set, and 2 idle Kubernetes node pools - **What the tags feed:** Terraform-applied tags across AWS, Microsoft Azure and Vercel, Kubernetes and Docker requests right-sized, Neon Serverless PostgreSQL idling to 0 and ClickHouse retention set deliberately. - **Who runs it:** finance and engineering together, in SaaS and Multi-tenant Architecture estates where cost per tenant is the only number that survives 10x growth. ## How to use this glossary Terms are grouped by the layer of the system they belong to rather than alphabetically, because the decisions they describe are usually made together. Every term page answers 4 questions in full and links to its neighbours, so a question about tenancy leads to row-level security and access control rather than ending at a definition. ## Sourcing Version numbers describe the stack ERPStack builds on. Regulatory figures cite the instrument they come from — 21 CFR Part 11, Regulation (EU) 2016/679, NIST SP 800-53 Rev. 5, 45 CFR Part 164 — so they can be checked at source. ERPStack holds no SOC 2 report, ISO 27001 certificate, PCI DSS attestation, HIPAA certification or FedRAMP authorisation; systems are engineered against those control baselines and documented so the assessor you appoint can test them.