Как построить архитектуру “serverless + edge” для глобального приложения

Ты хочешь, чтобы твоё приложение работало быстро для пользователя в Токио, Лондоне и Сан-Паулу — без лагов, без задержек, без костылей. Ты не хочешь управлять серверами, не хочешь тратить деньги на переизбыток ресурсов и не хочешь, чтобы твоя система падала при пиковой нагрузке. Ты не ищешь теорию. Ты хочешь понять, как собрать реальную архитектуру, которая работает сейчас, а не в идеальном мире.

Serverless + edge — это не модное словосочетание. Это практический способ построить глобальное приложение, которое масштабируется само, отвечает за миллисекунды и стоит меньше, чем традиционная инфраструктура. Я покажу, как это делается на практике — без воды, без маркетинга, только шаги, которые реально работают.

Что значит “serverless + edge” на деле?

Serverless — это не отсутствие серверов. Это отсутствие твоей ответственности за них. Ты пишешь код — он запускается, когда нужен, и останавливается, когда не нужен. Ты платишь только за время выполнения, а не за выделенные ядра.

Edge — это выполнение кода не в центре данных, а ближе к пользователю. Вместо того чтобы запрос шёл из Бразилии в США, он обрабатывается в ближайшем edge-узле — в Латинской Америке. Задержка падает с 300 мс до 30.

Соединяешь их — получаешь приложение, которое:

• Отвечает за 50–100 мс в любой точке мира
• Не требует управления инфраструктурой
• Автоматически масштабируется с 1 до 10 000 одновременных запросов
• Стоит в 3–5 раз меньше, чем кластер из виртуальных машин

Это не мечта. Это стандарт для таких компаний, как Vercel, Netlify, Cloudflare Workers, и даже крупных сервисов вроде Airbnb и Spotify.

Шаг 1: Определи, что именно ты хочешь развернуть

Не все приложения одинаковы. Ты не можешь взять шаблон из интернета и вставить туда свой код — это всегда провал. Начни с вопроса:

1. Что делает твоё приложение? (API? Сайт? Веб-приложение? Статика?)
2. Какие части требуют вычислений, а какие — только отдачи контента?
3. Есть ли состояние? (например, сессии, корзины, пользовательские настройки)

Пример:

• Статический сайт с формой обратной связи — идеален для serverless + edge. HTML, CSS, JS — на CDN, форма — через edge-функцию.
• Веб-приложение с реальным временем и базой данных — сложнее. Тебе нужны edge-функции для логики, но база данных — отдельно, и она должна быть глобальной.
• API-сервис с тяжёлыми вычислениями — edge не подходит для задач, требующих 2+ ГБ RAM. Тут нужна serverless-функция в центре данных, а не на краю.

Если ты не можешь ответить на эти вопросы — не начинай. Сначала разбери логику приложения, потом архитектуру.

Шаг 2: Выбери платформу — и не гонись за модой

На рынке три основных варианта. Ни один из них не идеален для всех. Вот что реально работает:

Платформа	Лучше всего для	Ограничения	Задержка (средняя)	Стоимость (примерно)
Cloudflare Workers	API, динамическая статика, кеширование, Wasm	Ограниченная память (128 МБ), нет встроенной БД	20–50 мс	$0.50 за 10 млн запросов
Vercel Edge Functions	Next.js, React, SSR, A/B-тесты	Только для Next.js-проектов, сложные вычисления — медленно	30–70 мс	$0.20 за 100 тыс. миллисекунд выполнения
Netlify Edge Functions	Статика + формы, JAMstack, CMS-интеграции	Меньше инструментов для сложной логики, медленнее старт	40–80 мс	$0.15 за 100 тыс. вызовов

Если ты пишешь на Next.js — выбирай Vercel. Это как шуруповёрт с встроенной отвёрткой — всё работает из коробки.

Если тебе нужна максимальная гибкость, контроль и низкая задержка — Cloudflare Workers. Там можно писать на JavaScript, TypeScript, даже на Rust через WebAssembly.

Если ты используешь WordPress, Shopify или другой CMS — Netlify проще. Там есть готовые плагины и интеграции.

Шаг 3: Собери архитектуру — по частям

Ты не строишь дом целиком — ты сначала фундамент, потом стены, потом крышу. То же самое здесь.

Часть 1: Статика — на CDN

HTML, CSS, JS, изображения — всё это кешируется на edge-сети. Никаких серверов. Только CDN. Cloudflare, Vercel, Netlify — всё это делают автоматически. Тебе нужно только:

• Собрать проект (npm run build)
• Загрузить артефакты (git push)
• Настроить TTL (время кеширования): 1 час для динамического контента, 1 день — для статики

Часть 2: Динамика — на edge-функциях

Ты хочешь, чтобы при загрузке страницы пользователь получал персонализированный контент — например, язык по геолокации, или промокод по IP. Это делается в edge-функции.

Пример: пользователь заходит с Бразилии. Edge-функция проверяет его IP, определяет страну, возвращает правильный язык и кеширует результат на 1 час. Следующие 1000 пользователей из Бразилии получат готовый ответ — без запуска кода.

Код функции на Cloudflare Workers:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const country = request.headers.get('CF-IPCountry');
    
    if (country === 'BR') {
      return new Response(
        '...',
        { headers: { 'Content-Type': 'text/html', 'Cache-Control': 'public, max-age=3600' } }
      );
    }
    
    return new Response(
      '...',
      { headers: { 'Content-Type': 'text/html', 'Cache-Control': 'public, max-age=3600' } }
    );
  }
};

Это 10 строк. Работает за 15 мс. Стоит 0,000001 доллара за вызов.

Часть 3: Данные — отдельно

Edge-функции не хранят данные. Они не могут. Память — 128 МБ максимум. И это не база данных.

Тебе нужна глобальная база данных. Выбери одну из трёх:

• Supabase — PostgreSQL с репликацией в нескольких регионах. Подходит, если ты знаешь SQL.
• Firebase Realtime Database — если тебе нужна синхронизация в реальном времени (чаты, уведомления).
• PlanetScale — MySQL-совместимая база с автоматическим масштабированием. Лучше всего для веб-приложений с транзакциями.

Соединяешь edge-функцию с базой через HTTPS-запрос. Не забудь:

• Использовать токены доступа, а не пароли
• Кешировать часто запрашиваемые данные на edge (например, список категорий — кешируй на 10 минут)
• Не делать запросы к БД на каждом вызове — это дорого и медленно

Шаг 4: Частые ошибки — и как их избежать

Вот что ломает 80% проектов, которые начинают с serverless + edge:

• Пытаться хранить сессии в памяти edge-функции. Каждый вызов — это новый контейнер. Сессии исчезают. Решение: используй JWT-токены или куки с подписью, хранящиеся на клиенте.
• Не кешировать ответы. Если ты запускаешь функцию на каждом запросе — ты теряешь смысл edge. Настрой TTL на 5–60 минут для статичных данных.
• Использовать тяжёлые библиотеки. Node.js-пакеты вроде Lodash или Moment.js могут увеличить размер функции в 5 раз. Используй только то, что реально нужно. В Cloudflare Workers можно писать на Deno или даже на Rust — это легче.
• Писать сложную логику на edge. Если твоя функция делает 3 запроса к БД, парсит JSON, считает статистику — она будет работать 500 мс. Это не edge. Это медленный сервер. Разбей на части: один edge-запрос — одна задача.
• Игнорировать мониторинг. Без логов и метрик ты не поймёшь, почему приложение медленно. Включи Cloudflare Analytics или Vercel’s Analytics. Смотри на P95 задержку — не на среднюю.

Что выбрать в зависимости от ситуации

Нет универсального решения. Вот как выбрать:

• Если ты стартап с MVP — используй Vercel + Supabase. Стартуешь за час, не думаешь про инфраструктуру. Масштабируешь, когда вырастешь.
• Если ты делаешь API для мобильного приложения — Cloudflare Workers + PlanetScale. Максимальная скорость, низкая стоимость, поддержка WebAssembly для шифрования на краю.
• Если у тебя CMS (WordPress, Contentful) — Netlify + его CDN. Интеграция с CMS — в один клик, кеширование — автоматически.
• Если тебе нужна безопасность на уровне края (например, защита от ботов, DDoS) — Cloudflare Workers. Там есть WAF, Rate Limiting, Bot Fight Mode — всё в одном месте.
• Если ты работаешь с видео или большими файлами — не используй edge для загрузки. Загружай на S3 или Cloudflare R2, а edge-функция только выдаёт ссылки и проверяет права доступа.

Как лучше сделать — практические рекомендации

Вот что я делаю в реальных проектах:

1. Всё статическое — на CDN. Даже favicon.ico и robots.txt. Никаких серверов.
2. Edge-функции — только для персонализации, аутентификации, редиректов, кеширования. Не для бизнес-логики.
3. База данных — всегда отдельно. Глобальная, с репликацией. Никаких локальных БД в edge.
4. Токены аутентификации — JWT, подписанные на сервере, хранятся в HTTP-only куках. Никаких localStorage.
5. Тестирование — запускаю функции локально с Wrangler (Cloudflare) или Vercel CLI. Не деплою без тестов.
6. Мониторинг — смотрю на P95 задержку, ошибки 5xx, количество вызовов. Если P95 > 200 мс — ищу проблему.
7. Затраты — контролирую ежедневно. Cloudflare показывает, сколько ты потратил за день. Если вдруг выросло в 10 раз — ищи утечку.

Совет: не пытайся сделать всё идеально с первого раза. Начни с простого: статика + одна edge-функция для смены языка. Потом добавь форму. Потом — авторизацию. Потом — базу данных. Маленькими шагами.

Итог: что делать прямо сейчас

Если ты читаешь это — ты уже на полпути. Ты не ищешь «что такое serverless». Ты хочешь сделать приложение, которое работает быстро для всех. Вот твой план на сегодня:

1. Определи: что делает твоё приложение? Статика? API? Динамика?
2. Выбери платформу: Vercel (если Next.js), Cloudflare (если нужен контроль), Netlify (если CMS).
3. Загрузи статику — просто. Никаких настроек.
4. Напиши одну edge-функцию: например, смена языка по IP.
5. Подключи глобальную БД (Supabase или PlanetScale).
6. Запусти. Проверь задержку через WebPageTest из разных стран.
7. Смотри на метрики. Если всё работает — добавляй следующий функционал.

Ты не должен знать всё. Ты должен начать. И делать шаг за шагом. Serverless + edge — это не про сложность. Это про простоту. Ты не управляешь серверами. Ты пишешь код. Он работает. Где угодно. Для кого угодно. И стоит копейки.

Сегодня ты можешь запустить глобальное приложение за 3 часа. Не за 3 недели. Не за 3 месяца. За 3 часа. Просто начни.

Информация в статье носит ознакомительный характер. Выбор инфраструктуры, архитектуры и технологий должен основываться на анализе конкретного бизнес-кейса и консультации с инженерами, специализирующимися на масштабируемых системах.