Connection pooling

Connection pooling переиспользует соединения с БД (или HTTP) вместо нового TCP+auth на каждый запрос. Pool **ограничен** — при исчерпании callers ждут или падают.

					const pool = new Pool({ max: 20, idleTimeoutMillis: 30000, connectionTimeoutMillis: 5000 });
				

| Параметр | Риск при ошибке | |----------|-----------------| | `max` слишком высокий | Перегруз `max_connections` БД | | `max` слишком низкий | Queueing и timeouts под нагрузкой | | Pool на инстанс | `instances × max` должен влезать в бюджет БД | | Нет timeout | Зависшие запросы копятся |

Считайте размер: если Postgres даёт 200 connections и 10 app instances, `max` на инстанс ~15–18 с запасом под admin и миграции.

На интервью: формула sizing; PgBouncer vs app pool; connection storms при deploy; serverless + БД.

Типовые ошибки: max 100 на каждом pod; нет timeout на acquire; длинные транзакции держат connection.

Компромисс — concurrency против безопасности БД и overhead соединений.

Чеклист:

• Суммарные connections по fleet.
• Acquire timeouts и метрики.
• Короткие транзакции.
• Внешний pooler при необходимости (PgBouncer).