Microsoft published the traffic behind your flow list
Microsoft's Power Platform Developer Blog published an engineering account on September 15, 2026, bylined Sanket Achari, Senior Software Engineer, covering the migration of the regional Redis deployments behind Copilot Studio agent flows and Power Automate workflows from Azure Cache for Redis Classic to Azure Managed Redis. Sitting inside it are production traffic figures for September 6 to 12, 2026. Europe averaged 10,922 reads per second and 4,010 writes per second. The United States averaged 10,263 reads per second and 3,678 writes per second.
Vendors almost never publish numbers like that for the infrastructure under a Power Platform service. Add the two regions and you get more than 21,000 reads and roughly 7,700 writes every second, sustained across an ordinary week. Microsoft describes the shared service as the primary backend for agent flows in Copilot Studio while it continues to support Power Automate workflows, handling flow creation and management along with sharing.
So the flow list your makers open and the designer they save from both read through a cache tier you do not administer and cannot see. When someone in your tenant says the environment feels sluggish before a single run has even started, this is one of the layers they are describing.
Four thousand writes a second is the figure to stare at
Reads outnumber writes by under three to one in both regions. That ratio is lower than we'd expect from a cache holding flow metadata, because nobody creates four thousand flows a second and nobody shares them at that rate either.
The post doesn't say what those writes are, and that's the part we'd ask about. Our guess is cache population on miss plus short-lived state written during management operations. Either way, your share of that write traffic scales with how much churn your makers generate, which is one more reason flow ownership debt and environment strategy are capacity questions before they are tidiness questions.
The load drop matters more than the cost headline
Redis server load fell from roughly 75% to 15% in Europe, and from 75 to 95% down to about 40% in the United States. Read the first pair of numbers again. A cache tier sitting at 75 to 95% has very little headroom left, and a tier under that kind of pressure stops being fast well before it stops answering.
If you have ever had a flow-heavy tenant drag in the designer with nothing in your own environment to blame, that load figure is a plausible explanation. Microsoft doesn't offer it as one. The post reports the load drop and makes no claim about past latency, which we read as appropriate caution.
The asymmetry deserves a question. The United States carried slightly less traffic than Europe and still landed at about 40% load against Europe's 15%. The post doesn't explain the gap. Our guess is different scale unit sizing or read paths that haven't moved yet, and it is only a guess. If your users sit in the region that stayed warmer, the first half hour of a platform incident goes better when your team already knows which layers they do not own.
A 95% hit rate still leaves hundreds of misses a second
The post reports an L1 cache hit rate of at least 95% for selected flow-access and billing-context reads. At Europe's 10,922 reads per second, a five percent miss rate still sends more than five hundred reads a second past the in-process cache. Design for the miss path, because it decides what your slow requests look like.
Two words in that claim deserve attention. Selected means the hit rate covers chosen read paths rather than everything the service reads. Billing-context means entitlement information is being cached, which implies a staleness window on whatever that context governs. The post gives no expiry or invalidation detail, and anyone designing agent flows against licence-sensitive behaviour should ask about it.
Read the 72% next to the cost table
The closure snapshot shows about 72% lower ongoing Redis costs against the pre-migration baseline, and that figure already includes the Azure Managed Redis spend that replaced the old capacity. The Classic Redis Premium component is down 88%. Both are real numbers. Neither of them describes a retirement.
Classic was still running at that snapshot. The cost table puts it at 12% of baseline, and the post says Classic continued serving workloads outside this migration's scope including sovereign cloud regions, with retirement described as a later phase. The 72% was measured while two Redis estates were live, and the remaining 12% covers work that was never in scope to begin with. Whether that line shrinks further depends on a phase Microsoft has not dated.
Credit to the team for publishing the table that lets you see this. A lot of migration write-ups would have led with the 88% and left the rest off the page. If you are building an internal business case off someone else's numbers, that table is the shape of evidence to ask your own platform team for.
The auth change is the part worth copying
The team also upgraded to StackExchange.Redis 3.0 and moved to Microsoft Entra authentication, removing the static-key fallback in migrated scopes only. That qualifier carries weight. Static keys still live wherever the migration has not reached, which by Microsoft's own description includes sovereign cloud regions and other workloads outside this scope.
You cannot switch any of this on in your own tenant. It belongs to the platform team. What you can copy is the order of operations: upgrade the client library, then move to identity, and only then remove keys where identity has proven out in production. Teams that run it the other way round end up with a rotation schedule they never finish and no clean date to point at.
Microsoft published a load graph for a service your makers depend on and cannot see. Ask your Microsoft contact for the equivalent figure for your region, and ask what that five percent miss path costs a maker saving a large flow on a Monday morning. If you are planning process-first agents on top of this tier, the worst answer you can get back is that nobody has measured it.
