The load-bearing decision here is a date. A license expiration, not an architectural preference, set the schedule: the first-generation platform was approaching end of life, which left just over three months to rebuild the orchestration layer before existing licenses expired [10]. Under that clock the team declined to implement state management, retries and failover, and adopted a distributed orchestrator instead, keeping the schedule for the defense logic [11]. Renewal dates are an underrated form of design review.
The requirements that purchase covers are stated plainly: execution across regions, fault tolerance, concurrency controls, and complete visibility across a globally distributed platform [14]. The cost shows up in how the code must be written. Salesforce says the team taught its coding assistants Temporal's programming patterns [13], and that detail is the interesting one. In my experience durable execution frameworks restrict what you may do inside a workflow body, and an assistant trained mostly on ordinary request handlers will happily write one that cannot be replayed. Teaching the model the framework's rules is not a nicety when more than 90% of a rewrite is AI-assisted [13].
Now the numbers. Roughly 20 trillion transactions a year [3] averages about 634,000 per second [15], and the figure that matters for this work is peak load, not average load. The number that matters is the peak the classification path has to handle while it is under attack, and that is not published.
Time to first mitigation fell 5x [2]. No baseline is given, so the figure only describes Salesforce's previous platform. For it to transfer, your current first mitigation would have to be human-paced rather than already automated at the edge. Your attack mix would have to be weighted toward the application layer, which Salesforce names as the harder case above network and transport [6]. And your mitigation action would have to be something an orchestrator can apply by itself, not a vendor ticket or a peering change that ends in someone else's queue.
The multi-tenant argument cuts both ways. Salesforce's own framing is that an attack on one customer consumes shared infrastructure and reaches many others [5], which is exactly why an automated mitigation that misreads legitimate traffic is a shared-fate event too. AI-driven inference on evolving attack patterns is one of the three stated design principles [8]. Salesforce does not state precision, recall, or the rollback path. The one thing I would credit the orchestrator choice for is that undo can be a step in the workflow rather than a paragraph in a runbook.
Scale the availability target against it: 99.99% across 4.5 million domains and 3 million orgs [4] permits about 52.6 minutes of unavailability a year [16], so mitigation latency is budgeted in minutes, and a human triage loop spends the year's allowance on two incidents. The migration figure deserves the same treatment. About 100,000 lines moved at roughly ten times previous velocity [12] implies something near 30 months of work at the old pace if it consumed the whole window [17]. Lines migrated is a weak proxy for effort, and the multiplier is self-reported by the team that chose the tooling.
