CleanStartFast for readers. Clear for editors.
CMS performance, correct cache timing, and product interfaces that make the next step clearer.
- 01Editor publishes
- 02Write commits
- 03Cache purges
- 04Reader sees update
Fast for readers. Clear for editors.
CleanStart’s web and CMS experience connects security products, a content catalog, resources, and reader journeys. The same system has to work for someone publishing content and someone discovering it.
The problem to work through
Relationship lookups multiplied in the CMS list view, and cache invalidation could run before a database write committed. Publishing could leave a new resource unavailable until a later revalidation.
Batch the repeated work
I batched CMS relationship lookups and separated publishing from integration work, reducing the request fan-out in the documented list view.
Make the timing correct
I moved cache purging after the write commits so revalidation reads the newly published state.
Design the next useful step
I worked on the reading-depth resource journey and its editor overrides, reduced the animation cost in a follow-up, and gave the Tricorder platform a clearer place in product navigation.
~75 to 2 relationship requests
The documented 25-row CMS list view. This measures relationship requests for that example, not total page requests or a universal speedup.
What I take from it
Performance and correctness often meet at the same boundary. A fast invalidation at the wrong moment still gives the reader the wrong page.