Если вы генерируете несколько сотен PDF в день на одной Lambda или небольшом pod в Kubernetes, архитектура редко решает судьбу проекта. Почти любой вариант работает и кажется достаточно быстрым.

Но на десятках тысяч документов в день все меняется. E-commerce invoices, shipping labels, BNPL receipts, payroll documents и billing platforms быстро приходят к такому объему. С этого момента начинают болеть три числа:

Cold-start latency, потому что где-то всегда есть холодная среда.
Regional latency, потому что клиенты не сидят рядом с origin.
Per-render compute, потому что вы платите за него тысячи раз в день.

На этом уровне edge-deployed renderer вроде gPdf уже не “тот же сервис, только быстрее”, а другая операционная модель.

1. Cold start умножается на пики нагрузки

Cold start не является единичной неприятностью. Он связан с формой вашей concurrency curve:

Вы держите 10 warm containers под средний трафик.
Приходит пик 3x: Black Friday, день зарплаты, конец квартала.
Для пика стартуют еще 20 containers.
Каждый тратит 1,5-2,5 секунды на Chromium, Prince или runtime.
В течение этого окна global p99 растет, а timeout budget вашего order pipeline уходит на PDF.

При ровном трафике это терпимо. Но PDF-трафик редко ровный: invoices появляются на границах billing cycles, labels в окнах отгрузки, statements в конце месяца.

Edge-вариант: Cloudflare Worker isolate стартует за 5-20 ms, а не за секунды. Нет контейнера, браузера или JVM, которые нужно поднимать. WASM module загружается в уже живой процесс. В benchmarks gPdf худший cold start около 12 ms, и только для первого запроса на новом isolate.

2. Региональная задержка реальна даже для быстрых renders

Sydney до us-east-1 дает около 200 ms еще до выполнения кода. Sao Paulo до eu-west-1 около 190 ms. Mumbai до US East около 220 ms.

Если centralized PDF API делает server-side render за 300 ms, пользователь в Sydney видит примерно это:

client -> us-east  : 200 ms
us-east render     : 300 ms
us-east -> client  : 200 ms
total wall-clock   : 700 ms

Для backend batch job это может быть незаметно. Для invoice preview перед отправкой это уже ощущается.

Edge-вариант: Cloudflare работает в сотнях городов. Ближайший к Sydney colo может быть примерно в 5 ms:

client -> SYD colo : 5 ms
SYD render         : 4 ms
SYD -> client      : 5 ms
total wall-clock   : 14 ms

Для интерактивных сценариев это меняет продуктовый опыт. Кроме того, если PDF API работает на edge, туда можно перенести auth check, rate limit и checkout preview. Каждый такой перенос убирает round trip из hot path.

3. Стоимость одного render копится тихо

При 100 000 рендеров/day:

Puppeteer с ~600 ms и 1024 MB: примерно 240 USD/мес. только за compute, без egress и ops.
DocRaptor по $89 за 100 000 страниц: примерно 2,670 USD/мес. при 3 млн страниц/мес..
gPdf по $5 за 100 000 страниц: примерно **150 USD/мес.** при 100 000/day, или$ 5 при ровно 100 000/month.

При 1 млн renders/day разрыв шире:

Puppeteer: ~2,400 USD/мес. + ops + on-call.
DocRaptor: ~26,700 USD/мес..
gPdf: около ~1,500 USD/мес. по volume pricing.

Причина проста: стоимость PDF generation задает footprint renderer. Замена Chromium process на сотни MB небольшим WASM module меняет unit economics.

Что edge дает на практике

Предсказуемая latency под нагрузкой

Когда нет boot cost на каждый запрос, p50 и p99 держатся рядом. У gPdf p99 обычно остается в пределах 3x от p50 даже во время пиков. У Puppeteer cold-start storms могут увести p99 к 10x.

Один artifact для всех регионов

.wasm module одинаково деплоится в каждый Cloudflare colo. Не нужно гадать, прогрет ли Sydney pool, и управлять regional concurrency reservations.

Путь к embedded deployment

Если enterprise-клиент захочет запуск внутри VPC, isolated cluster или air-gapped intranet, тот же WASM module подходит. Это не только hosted SaaS, а переносимая технология.

Где edge не лучший выбор

Renders на десятки секунд. Огромные financial statements или scientific reports лучше жить в long-running containers.
Renders рядом с базой данных. Если нужны тяжелые OLAP JOINs, выполните их рядом с DB и отправьте final JSON на edge.
Stateful post-processing. Signing, archival и multi-step watermark pipelines могут требовать central workflow.

Для большинства B2B invoices, labels и receipts edge выигрывает по latency, cost и operations.

Когда пора перестать терпеть текущую схему

Если совпали три пункта, математика миграции уже изменилась:

PDF infrastructure стоит больше 300 USD/мес..
PDF p99 выше 800 ms при обычном трафике.
Cold-start incident уже затронул клиентов.
Вы потратили больше 4 часов на CJK, RTL или emoji glyphs.
PDF генерируется в interactive flow.
Вы работаете более чем в одном регионе.

Первые три пункта означают, что вы платите больше и все равно получаете худшую latency. Следующие показывают, что centralized renderer ограничивает продукт.

Если это похоже на вашу ситуацию, Playground сгенерирует sample invoice в браузере менее чем за 5 ms.