db.collection.aggregate( [
   { $group: { _id: null, myCount: { $sum: 1 } } },
   { $project: { _id: 0 } }
] )

$group is a blocking stage, which causes the pipeline to wait for all input data to be retrieved for the blocking stage before processing the data. A blocking stage may reduce performance because it reduces parallel processing for a pipeline with multiple stages. A blocking stage may also use substantial amounts of memory for large data sets.

Optimized concurrency: Functions can handle multiple requests per instance, reducing idle time and lowering compute costs by up to 85% for high-concurrency workloads

Cold start protection: Fewer cold starts with smarter scaling and pre-warmed instances

Optimized scaling: Functions scale before instances, moving beyond the traditional 1:1 invocation-to-instance model

Extended function lifecycle: Use waitUntil to run background tasks after responding to the client

Runaway cost protection: Detects and stops infinite loops and excessive invocations

Multi-region execution: Requests are routed to the nearest of your selected compute region for better performance

Node.js and Python support: No restrictions on native modules or standard libraries

I/O bound backends like AI inference, agents, MCP servers, and anything that needs to scale instantly, but often remains idle between operations. These workloads do not follow traditional, quick request-response patterns. They’re long-running, unpredictable, and use cloud resources in new ways.

I/O-bound refers to a process that is limited by input/output operations rather than CPU speed. These tasks spend most of their time waiting for external resources, such as database queries, API requests, or file system operations, rather than performing computations. Optimizing I/O-bound tasks often involves concurrency to maximize resource efficiency.

Instead of spinning up a separate instance for each invocation, Fluid compute intelligently orchestrates compute across invocations. Multiple concurrent requests can share the same underlying resources, eliminating cold starts and reusing idle time. This allows I/O bound workloads like AI to run more efficiently.

Even with high concurrency, there could still be moments where all invocations are waiting on external responses and no code is actively running. During these idle periods, functions stay in memory, doing no work, yet still incur CPU cost.

It's a new pricing model that charges for CPU only when your code is actively using the CPU.

- CF Workers
- AWS Lambda
- Vercel Serverless
- Vercel Serverless server (Fluid Compute) w/o Active CPU Billing
- Vercel Serverless server (Fluid Compute) with Active CPU Billing

- [CPU] верификация юзера + проверки доступов
- [idle] ожидания ответа из бд / inference
- [CPU] трансформация ответа из бд и подготовка ответа клиенту (либо рендер html из json)

Serverless: 80s * 100 = 8000s
Fluid: 80s * 1 req = 80s
Net CPU: 5ms*100 req = 500ms = 0.5s

Fluid Compute (serverless servers) = one node that can resolve multiple users requests but only has one binary (one piece of code running on it)
Cloudflare solution = lots of different developers codes running on the same box at the same time (abstracting per function call level)

— Как называется эта часть?
— Какие слова в ней допустимы?
— В каком контексте они значат то, что значат?

Практические примеры (финтех):
Интернет-банк разбивается на контексты: «Accounts» (Счета), «Payments» (Платежи), «Loans» (Кредиты), «Cards» (Карты), «Analytics/Reporting» (Отчеты). Каждый из них соответствует своей части бизнеса и управляется отдельной командой. Например, команда контекста Payments владеет всем, что связано с переводами: у них свой словарь (платеж, транзакция, комиссионные и т.д.) и своя кодовая база. В другом контексте Accounts – свой словарь (баланс, счет, клиент и т.п.). Эти команды работают параллельно, а взаимодействуют их сервисы через четко определенные API. При этом термин «Transaction» в контексте платежей имеет одно значение (конкретное движение денег), а в контексте аналитики, скажем, это может быть абстрактный объект для агрегированной статистики. Благодаря DDD эти понятия разведены: без выделения контекстов компания получила бы единую громоздкую систему, где разные отделы говорили бы «транзакция» о разном и путали друг друга. 
В этом примере команда Accounts и команда Payments могут работать автономно, выпуская изменения независимо – изменение в сервисе счетов не сломает сервис платежей, если контракт (например, API запроса баланса) остался прежним.