A CRM-Backed Portal That Reads From the Edge
“CRMs are fine databases and poor web servers - so stop serving the web from them directly.”
Pattern study: keep the CRM authoritative, serve browsing from cache, and let change events do the invalidation.
PORTALSCHANGE EVENTSNEXT.JSAPI GATEWAY
Fixture portal browses from edge with record reads reserved for writes and misses
What Made the Problem Difficult
Independent work, fixtures only. Legacy portal stacks often read record data per page view, which couples browsing latency to record-API budgets. I modeled the decoupled alternative to see how much machinery it really takes.
Core Platform Constraint
Systemic FrictionPer-view record reads exhaust API allowances at peak and still feel slow on mobile. The portal inherits the record system's release and maintenance windows whether users like it or not.
- !Record system stays the sole authority in the study model
- !Browsing must survive record-API budgets and stay fast on mobile
- !Writes stay atomic across related fixture entities
- !Staleness windows are explicit and visible, never silent
What System Was Designed
Next.js at the edge, a thin caching gateway, and async invalidation. Change events on fixture entities evict affected cache entries; the gateway validates event signatures before acting. Mutations travel as composite payloads; the UI applies them optimistically and reconciles on confirmation.
Pivotal Architectural Choices
Key Architectural Decisions
Edge cache with event invalidation
Per-view record reads burn budget for unchanged data.
- Direct record reads per visitor
- Nightly batch exports
Browsing stops costing record-API calls while staying close to fresh.
Composite mutations for related writes
Multi-entity workflows split across calls fail partially.
- Sequential single-entity calls
- Bespoke server endpoints per flow
Atomicity plus fewer calls - the two wins come together.
What Was Actually Built
Defined fixture change streams for representative entities with signed invalidation webhooks.
Built the gateway to validate signatures, scope cache keys, and evict precisely.
Batched related fixture writes into single composite payloads with rollback semantics in the study model.
Rendered portal pages from edge cache with optimistic mutation states reconciled in the background.
Deliberate Architectural Compromises
Trade-offs & Mitigations
⚖Custom portal vs. out-of-the-box community
Full control of performance, branding, and access costs in the study.
A portal and gateway to own.
Shared design tokens and standard CI pipelines keep the ownership boring.
⚖Cached freshness vs. live reads
Fast browsing, insulated from record-system downtime.
Seconds of staleness after writes.
Optimistic UI plus explicit freshness indicators per surface.
Verified Outcomes
Fixture portal browses from edge with record reads reserved for writes and misses
Record-API consumption in the study model falls to a fraction of per-view polling
Related-entity writes commit atomically in the fixture harness
Staleness behavior is documented per surface rather than discovered by users
System Schematic & Data Flow
High-speed modern client decoupled from CRM governor limits via asynchronous event cache invalidation.
Text alternative for screen readers: Architecture flow: Customer Client to Edge Gateway / Cache via Sub-100ms Read Access; Customer Write to Micro-Gateway API via Authenticated Mutation; Micro-Gateway API to Salesforce Composite API via Batched Deterministic Write; Salesforce CDC to Cache Invalidation Webhook via Near-Real-Time Stream
Architectural Conclusion
“Enterprise CRMs are magnificent transactional databases and workflow engines, but poor public web servers.”
- •Enterprise CRMs are magnificent transactional databases and workflow engines, but poor public web servers.
- •Decoupling the experience layer with event streaming transforms an enterprise platform into a competitive advantage.