Skip to main content
INDEPENDENT RESEARCH · HEADLESS · REVENUE CLOUD (RCA) · API-LEDTier 1 Flagship

Headless Salesforce Revenue Cloud (RCA) Capabilities, Without Dual Maintenance

“Separate capability from presentation - but keep exactly one engine that owns the truth.”

A pattern study: keep pricing and configuration authority in one engine, serve every channel from versioned contracts.

HEADLESSAPI-LEDCONTRACT-FIRSTRCA

Executive BriefHeadless
Domain / ScopeHeadless Platform Architecture
Architectural RoleIndependent Architect
Timeline & InitiativeIndependent research · 2025–2026
Key Verified Invariant

Demo engine serves web, partner, and internal fixture clients from one contract set

01 · The Constraint

What Made the Problem Difficult

Independent work, demo contracts only. Revenue logic has to reach many surfaces - self-service, partner, mobile, internal - and every surface team eventually proposes owning a copy. I modeled the alternative I trust: one engine, many readers, contracts in between.

Core Platform Constraint

Systemic Friction

Binding engine logic to internal page layouts leaves two bad options: force outsiders onto internal screens, or copy the logic outward and maintain both. Copies always diverge - usually discovered as misquotes.

Boundary Invariants & Operational Limits:
  • !One authoritative engine for price, configuration, and contract rules in the study model
  • !External consumers integrate only through versioned contracts
  • !Public-traffic patterns must respect platform rate limits
  • !Catalog reads stay fast; transactional calculations stay exact
02 · The Architecture

What System Was Designed

A gateway sits between experience surfaces and engine capabilities. It translates auth, enforces budgets, and aggregates multi-step inquiries into single-turn composite calls. Catalog metadata rides edge cache with contract-aware invalidation; live calculations pass through to the engine. Client libraries for React and web components share the same schemas.

03 · The Key Decision

Pivotal Architectural Choices

Key Architectural Decisions

ADR // 01DETERMINISTIC CHOICE

Headless capability layer vs. rewriting the engine outside

Context:

Rewriting pricing externally is fast to start and slow to own.

Alternatives Evaluated:
  • Rebuilding the engine in external microservices
  • Iframing internal screens
Chosen: Keep the study-model engine authoritative; expose it through contracts.

One implementation to fix, many surfaces to serve. Frontend teams keep full visual freedom without owning arithmetic.

ADR // 02DETERMINISTIC CHOICE

Edge caching for catalog, pass-through for transactions

Context:

Reads and calculations have different freshness needs.

Alternatives Evaluated:
  • Pass everything through live
  • Nightly batch syncs
Chosen: Cache catalog dimensions at the edge; calculate transactions live.

Browsing stays instant and cheap while money math stays exact.

04 · The Engineering

What Was Actually Built

01

Authored demo REST/GraphQL contracts that hide internal object shapes behind stable fields.

02

Built the gateway concerns explicitly: auth translation, per-route budgets, and response aggregation.

03

Designed composite endpoints so one configurator turn costs one call, not five.

04

Shipped thin client libraries sharing the same schemas across React and web-component consumers.

05 · The Trade-offs

Deliberate Architectural Compromises

Trade-offs & Mitigations

⚖Gateway ownership vs. direct calls

Architectural Benefit:

Uniform contracts, budgets, and auth across channels.

Associated Cost:

A gateway to run and version.

Mitigation Strategy:

Contract tests in CI that fail the build on breaking schema drift.

⚖Live calculation vs. limit budgets

Architectural Benefit:

Exact quotes on every transaction.

Associated Cost:

Public traffic can press platform allowances.

Mitigation Strategy:

Cache everything cacheable; reserve live calls for money math with session-scoped tokens.

06 · The Result

Verified Outcomes

✓ VERIFIED RESULT

Demo engine serves web, partner, and internal fixture clients from one contract set

✓ VERIFIED RESULT

No duplicated pricing logic across demo surfaces

✓ VERIFIED RESULT

Catalog browsing served from edge in the study setup; transactions calculate live

✓ VERIFIED RESULT

Breaking contract changes surface in CI before deployment in the harness

07 · Architecture Blueprint

System Schematic & Data Flow

System Topology Blueprint
Headless Salesforce Revenue Cloud (RCA) Capability Study
INTERACTIVE SCHEMATIC
OMNICHANNEL EXPERIENCE LAYER (DECOUPLED SURFACES)Modern React StorefrontPartner Dealer PortalNative Salesforce LWC Screencontract-first REST / GraphQLHEADLESS API & CONTRACT GOVERNANCE GATEWAYSession State Mediation · Quota Shielding · Schema EnvelopesSALESFORCE RCA · ENTERPRISE CAPABILITY PLATFORMPricing EngineTiered matrices & discountsConfig EngineAttribute resolutionRule EvaluatorContract & validity rules
CAPABILITY DECOUPLINGSalesforce functions as an enterprise capability platform, not solely as a UI container.
SINGLE SOURCE PRICINGEliminates pricing logic duplication in middleware; RCA maintains absolute authority.
OMNICHANNEL PORTABILITYReact storefronts, mobile clients, and LWC surfaces consume identical contracts.

One demo engine, versioned contracts, edge-cached catalog with live transactional calculation.

Text alternative for screen readers: Architecture flow: Experience Surfaces (React / LWC) to Headless API Gateway via Contract-First Ingress; Headless API Gateway to Demo Salesforce Revenue Cloud (RCA) Engine via Composite Orchestration; Demo Salesforce Revenue Cloud (RCA) Engine to Pricing, Config & Rules via Single Authority; Pricing, Config & Rules to Omnichannel Fixtures via Unified Schema Response

08 · Why It Matters

Architectural Conclusion

“A capability outgrows its original UI the day a second channel needs it. Contracts are how it survives the trip.”

Key Lessons for Platform Scale:
  • •Keep one engine authoritative; let as many surfaces read it as contracts allow.
  • •Cache what is stable, calculate what involves money - and write down which is which.