That thought was the wrong problem. It took three months to find the right one.
How 50,000 Claims a Day Breaks Your Assumptions
The math that fooled me looked reasonable on its face.
Fifty thousand claims a day at the individual record level is manageable. The problem is that healthcare claims do not travel alone. Each claim brings claim lines, service codes, member information, payer adjudication details, and in many cases supporting documentation. Count the full object graph and a single claim touches anywhere from five to ten records across the org. At fifty thousand claims a day, that is potentially half a million new records every twenty-four hours.
Salesforce data storage is generous by many standards, but it is finite. And retention obligations mean you cannot delete claims. State law and payer contracts set the floors, commonly six to ten years, with some contracts running longer. Every record written today lives on the org for years. The trajectory only goes one direction.
By month four the math was clear. What I was going to do about it was not.
The obvious answers arrived quickly and fell apart just as fast.
More storage was the first call I made. At the per-gigabyte rates for Salesforce storage and the volume I was writing, it was a deadline extension, expensive and temporary. I was buying weeks, maybe months, and the trajectory would catch up.
The platform's native archival storage layer looked more promising. Designed for scale and long retention, it handles volume without complaint. The wall I hit was practical: standard reports cannot read from it. Declarative automation cannot query it in any meaningful sense. Writing data in was fine; getting it back out in usable form required custom development for every access pattern. The moment I needed to correlate a historical claim with a current member record, I was writing code that fought the platform. That was not a viable path.
Third-party archival tools introduced new operational dependencies, new contracts, and pricing that compounds with volume. Two evaluations, two passes.
By the end of that sweep I had exhausted every solution I knew to reach for. The problem was still there.
The Question I Kept Missing
I had been treating this as a storage problem for three months. Every path traced back to space: buy more of it, compress it, move it somewhere cheaper. I kept running the same evaluation loop because I kept starting from the same assumption.
The shift came during a design review, when someone asked a question I could not answer cleanly: what do we actually do with a claim after it closes? How do we use it, as opposed to just keeping it? I had been so focused on the retention requirement that I had never separated retention from operational use. A closed claim sitting in Salesforce for seven years satisfies a compliance floor, but nobody is running a workflow against it. Nobody is updating it. The claim in flight and the case under review are categorically different from the record that just needs to survive for a decade.
Salesforce is built for that first category. It manages active state: running workflows, live records that people and processes are reading and writing. Long-term bulk retention at scale is a different job, and the platform was never designed to carry both at the same volume and the same time horizon.
Once I had that distinction clear, the storage limit started to look like a signal rather than an obstacle. The platform had been communicating its design intent the whole time. I had been looking for ways around that signal for three months instead of reading it.
Two tiers, each doing the job it was built for.
The Architecture That Named Its Own Boundaries
The first tier stays in Salesforce. It holds the active claims window, the data that people are actually touching, that workflows run against, that automations read and write. We settled on a ninety-day rolling window for claims in active status. Everything needed for daily operations lives here, on the platform that does daily operations well. Native reports work. Declarative flows work. Every Salesforce capability that matters for operational work functions against this tier without constraint.
The second tier lives in cloud storage and a relational layer built for archival and analytical workloads. When claims age past the active window, they move here. The full record is preserved, everything a compliance audit or retrospective analysis would need, but the data no longer consumes Salesforce storage because it no longer lives there.
Between the two tiers sits a lightweight sync process. On a schedule, it identifies claims that have crossed the age threshold, writes them to the cold tier with full field mapping, and removes them from the hot tier after confirming the write succeeded. The removal from Salesforce frees storage. The write to cold storage preserves compliance.
The detail that made this architecture worth the overhead was the service layer in front of both tiers. Downstream programmatic consumers do not need to know which tier a given claim lives in. They call a service with a claim identifier. The service routes the request to the correct store and returns the data in the same shape regardless of source. From the perspective of application code, there is one claims store. On the inside, there are two, each doing the job it was built for.
That routing runs as an Apex service layer: it checks the active tier first and falls through to the cold-tier API when the record is not found there. The residual constraint is real and worth naming directly. Native Salesforce reports and declarative automation see only the hot tier. They always did, and that remains true after the abstraction is in place. The unified view the service layer provides is for programmatic access, API consumers, integrations, and custom screens, not for point-and-click tooling. Because operational work happens within the active window, this has not been a practical limitation. It is a real constraint, and any team adopting this pattern needs to design operational reporting within the active window rather than assume the abstraction eliminates the cold-tier visibility gap.
The storage problem went away because we stopped asking Salesforce to carry both jobs. We drew a line at what the platform was actually built for and built the second tier on the other side of that line.
What the Volume Was Really Saying
The overhead is real. There is a sync process to monitor, a mapping layer to maintain, a cold-tier schema that has to stay aligned with the Salesforce schema as both evolve. At this volume it is still cheaper than buying additional storage or licensing third-party tooling, and the operational stability has been the biggest return.
The part that stays with me is simpler than the architecture.
Every tool I evaluated tried to give Salesforce more room to do what it was already doing. More capacity, smarter compression, a different place to offload the overflow. Those approaches kept finding the same ceiling because the ceiling was the framing. The platform communicated its own limits clearly enough; I kept looking for ways around them instead of asking what they meant.
Fifty thousand claims a day runs fine. That volume held across a decade of retention in a single operational system, with the same access patterns serving both live workflow and compliance archival, is where the load becomes unsustainable. The two-tier split holds because it respects what each layer was designed for. Take that boundary away, and the math comes back.