DEV Community: Franchesco Romero

Coordinar deploys de frontend y backend sin orquestado, usando Github Actions

Franchesco Romero — Thu, 28 May 2026 16:52:34 +0000

El Setup

Un setup chiquito de SPA + API donde dos workflows de GitHub Actions
salen en paralelo en cada push a main. Probablemente un setup que no usaría en prod, pero algo que si uso para mis proyectos personales.

Ahora bien esto trae un problema de coordinación (el frontend llega a los usuarios antes de que exista el endpoint de la API), cuatro opciones, y el gate de ~80 líneas de bash que fue el ganador para nuestro caso de uso

El codebase: una SPA de React en CloudFront + S3, un backend FastAPI en AWS ECS Fargate, infraestructura en CDK.
Dos workflows (deploy-frontend.yml, deploy-backend.yml) disparados por push a main con path filters.

Acá el código para seguir el post paso a paso:

elchesco / github-actions-combined-deploy-with-no-orchestrator

Coordinating frontend and backend deploys without an orchestrator:

Code companion — frontend/backend deploy coordination post

Each folder maps to one stage of the post's narrative:

00-independent/         starting point — two workflows, no gate, the race exists
01-coupled-detection/   git diff vs the parent commit to know if backend changed
02-poll-by-sha/         GitHub Actions API filtered by head_sha
03-grace-window/        handle "backend run not registered yet" (race fix)
04-final/               full step with meaningful error surfacing

Notes

00-independent/ is two separate files — they exist as .yml so you can diff them against your own workflows.
04-final/ contains the complete step block plus the workflow permissions and checkout config it depends on. Copy all three pieces or the gate will silently fail open.
The actions: read permission is…

View on GitHub

TL;DR

El approach simple aguanta mientras tu push esté dominado por
cambios de un solo dominio. Deja de funcionar cuando la mayoría de los pushes tocan los dos o más.

El problema

Dos workflows en la misma branch main:

# deploy-frontend.yml
on:
  push:
    branches: [main]
    paths: ["frontend/**"]

# deploy-backend.yml
on:
  push:
    branches: [main]
    paths: ["backend/**", "infra/**"]

Un push que toca los dos — digamos, "agrega el endpoint
/api/v1/leaderboard y la UI que lo llama" — dispara ambos workflows
en paralelo. Los builds de frontend normalmente son más rápidos (sin
Docker, sin rollout de ECS). Así que un usuario que refresca entre el
minuto 2 (SPA subida) y el minuto 6 (backend sano en ECS) pega contra
una SPA nuevecita apuntando a un endpoint que todavía no existe. La
consola del browser muestra un 404. Sentry pega un brinco, se disparan alertas de Cloudwatch, el usuario recarga, pega contra el caché, y ve el mismo error.

Difícil de cachar en dev porque el stack local arranca los dos servicios juntos. Fácil de cachar en prod una vez que pasa.

Las opciones

Opción 1: workflows paralelos independientes (el baseline de no hacer nada)

Con lo que arrancamos. Cada workflow escucha sus propios paths y
despliega en su propio tiempo. Cero coordinación.

# ambos workflows
on:
  push:
    branches: [main]
    paths: [...]

Pros:
cero setup, deploys de un solo dominio lo más rápido posible,
aislamiento total.
Contras:
la ventana de race de arriba. El costo solo aparece en los pushes acoplados.

Opción 2: colapsar en un solo workflow con orden explícito

El fix más "obvio": escribir un deploy.yml con deploy-backend como job 1 y deploy-frontend con needs: [deploy-backend].

jobs:
  deploy-backend:
    runs-on: self-hosted
    steps: [...]
  deploy-frontend:
    needs: [deploy-backend]
    runs-on: self-hosted
    steps: [...]

Pros:
modelo mental trivial; GitHub Actions maneja el orden.
Contras:
un push de solo-frontend ahora espera por un backend que no cambió (o
necesita un if: explícito para saltárselo, que es su propia
complejidad). Un step de lint flaky en el backend bloquea el deploy de frontend que ni siquiera dependía de los cambios del backend. Perdimos la independencia de path filters que hacía deseables los workflows paralelos para empezar.

Opción 3: el frontend gatea contra el SHA del backend (el gate simple)

Conservar los dos workflows. Agregar un step al inicio del workflow de frontend: si este commit también tocó backend, espera a que el
workflow de backend en el mismo SHA termine bien.

Pros:
cero overhead en pushes desacoplados (el caso común); se conserva
el paralelismo del caso común; el gate son ~80 líneas de bash + un
curl a la API de GitHub Actions. Sin infra nueva, sin servicio
orquestador, sin artifact pinning.

Contras:
bash. Polling. El gate corre en el runner del frontend, así
que cuesta minutos de runner mientras espera (gratis en self-hosted,
facturable en ubuntu-latest).

Opción 4: pin del frontend a un artifact buildeado del backend

La respuesta correcta de principio: cada build de frontend embebe la
versión de backend contra la que se construyó; la SPA se niega a llamar una API que no haga match.

// frontend
const REQUIRED_API_VERSION = "2026.05.27.a"; // inyectado en el build
if (apiHealthcheck.version !== REQUIRED_API_VERSION) showStaleBanner();

Pros:
cero ventana de race incluso con rollouts totalmente independientes; el cliente puede caer a un banner de "refresca para actualizar"; funciona durante rollbacks.
Contras:
cada cambio de endpoint se vuelve un contrato versionado; necesitas un endpoint de discovery /api/version y lógica en la SPA para manejar el mismatch; coordinar across clientes móviles eventualmente cuesta más que el gate.

Cómo elegir

Patrón de push	Mejor opción
Pushes mayormente de un solo dominio	Opción 3 (gate)
Pushes mayormente acoplados	Opción 2 (un solo workflow)
Clientes de larga vida / móvil / offline / una app de escritorio que no puedes forzar a refrescar	Opción 4 (contrato versionado)

Nuestra distribución: ~80% solo-backend, ~15% solo-frontend, ~5%
acoplado. La Opción 3 fue el match obvio. El resto del post es su
evolución.

Etapa 0: el punto de partida

Dos workflows, sin coordinación:

# .github/workflows/deploy-frontend.yml
name: Deploy Frontend
on:
  push:
    branches: [main]
    paths:
      - "frontend/**"
      - ".github/workflows/deploy-frontend.yml"
jobs:
  build-and-deploy:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v5
      - run: pnpm install --frozen-lockfile && pnpm build
      - run: aws s3 sync dist s3://myapp-frontend
      - run: aws cloudfront create-invalidation --distribution-id $DIST_ID --paths '/*'

Push acoplado → race → 404s en producción.
Fix: gatear el deploy de frontend contra el de backend cuando el commit cambió código de backend.

Etapa 1: detectar el push acoplado

Antes de hacer nada más, el gate tiene que responder: ¿este commit de verdad tocó el backend? Si no, no esperamos, procede de inmediato y no desperdicies un minuto de runner.

- uses: actions/checkout@v5
  with:
    # Necesitamos ≥ 2 commits para diffear contra el padre.
    fetch-depth: 2

- name: Detect coupled push
  run: |
    set -euo pipefail
    changed=$(git diff --name-only HEAD~1 HEAD 2>/dev/null || true)
    if ! echo "$changed" | grep -qE "^(backend/|infra/|\.github/workflows/deploy-backend\.yml$)"; then
      echo "No backend/infra changes — proceeding."
      exit 0
    fi
    echo "Backend changes detected — gate engaged."

El patrón de paths espeja el bloque paths: de deploy-backend.yml
exactito — si un path dispara el workflow de backend, el gate tiene que esperarlo. La diferencia entre los dos es la causa #1 de false
proceeds, así que mantenlos pegaditos en el code review.

El fetch-depth: 2 es la trampa — actions/checkout@v5 viene por
default en shallow 1, y git diff HEAD~1 en un checkout de depth-1
regresa nada en silencio, lo cual el script lee como "no hay cambios de backend — procede". (Pegamos contra esto en el primer deploy después de shipear el gate. Cáchalo con un guard, no nomás con documentación.)

Etapa 2: hacer poll al run del backend por SHA

Ahora sabemos que hay que esperar. El mecanismo es la REST API de
GitHub Actions filtrada por head_sha:

api="https://api.github.com/repos/${GITHUB_REPOSITORY}/actions/workflows/deploy-backend.yml/runs"
query="head_sha=${GITHUB_SHA}&per_page=1"

for i in $(seq 1 160); do  # techo de 40 min a 15s/poll
  payload=$(curl -sS \
    -H "Authorization: Bearer ${GH_TOKEN}" \
    -H "Accept: application/vnd.github+json" \
    "${api}?${query}")
  status=$(echo "$payload" | jq -r '.workflow_runs[0].status // empty')
  conclusion=$(echo "$payload" | jq -r '.workflow_runs[0].conclusion // empty')
  if [ "$status" = "completed" ]; then
    case "$conclusion" in
      success|skipped) exit 0 ;;
      *) echo "::error::Backend ${conclusion}"; exit 1 ;;
    esac
  fi
  sleep 15
done
echo "::error::Timed out waiting for backend deploy."; exit 1

El filtro head_sha es el eje de todo — regresa el run de este commit exacto, no "el último run en main", que haría race con un push de fast-follow.

El permiso actions: read se tiene que agregar al bloque permissions: del workflow — sin eso la API regresa 403 y el gate
falla open en silencio.

Etapa 3: manejar el "todavía no se registra"

El primer run en prod reveló un race: el workflow de frontend puede
arrancar antes de que GitHub haya registrado el run del workflow de
backend en el mismo SHA. La API regresa total_count: 0, el script lee "no hay run de backend en este SHA, procede", y ya volvimos al problema original del 404.

Fix: una grace window. Dale a GitHub hasta 30s para registrar el run.

# Grace window — espera hasta 30s a que aparezca el run de backend.
for i in $(seq 1 6); do
  count=$(curl ... | jq -r '.total_count')
  [ "$count" != "0" ] && break
  sleep 5
done

Los 30s son empíricos — medí unos cuantos pushes acoplados, el delay de registro siempre fue < 10s pero brincó a 18s una vez durante un
incidente de GitHub. 30s es lo suficientemente generoso como para que
no hagamos false-proceed; el timeout exterior de 40 minutos absorbe el costo.

Si después de 30s el run sigue sin existir, el script sí cae a "no
hay run en este SHA — procede". Esa es la decisión correcta: o el
workflow de backend no se disparó (el path filter excluyó los cambios), o GitHub está tan degradado que un deploy de frontend es el menor de nuestros problemas. No le busques tres pies al gato.

Etapa 4: superficies de error con sentido

Dos modos de falla necesitan manejo explícito para que el dev que ve el build en rojo pueda actuar:

# 1. La API de GitHub regresa 4xx (auth, rate limit, etc.).
fetch_runs() {
  local response status body
  response=$(curl -sS -w "\n%{http_code}" ...)
  status=$(echo "$response" | tail -n1)
  body=$(echo "$response" | sed '$d')
  if [ "$status" != "200" ]; then
    echo "::error::GitHub API returned ${status}: ${body}" >&2
    return 1
  fi
  echo "$body"
}

curl -f sale con 22 sin body. El wrapper conserva el body para que el log de error diga "403 Forbidden: actions read permission missing" en lugar de "exit code 22, suerte".

# 2. El deploy de backend falló — saca la conclusion tal cual.
*) echo "::error::Backend deploy ${conclusion}. Abortando el deploy de frontend para que la SPA nunca apunte a una API ausente." ;;

Los casos failure|cancelled|timed_out todos colapsan a la misma
acción (no deployar el frontend), pero imprimir la conclusion exacta te ahorra un click hacia el run del workflow de backend cuando estás
investigando.

El resultado

Un setup de dos workflows que:

Cuesta 0 segundos en pushes desacoplados (el caso del 80%)
Cuesta a lo mucho el wall time del deploy de backend en pushes acoplados
Falla closed — si el deploy de backend falla, el frontend no shipea (sin tormenta de 404s)
Falla closed en el gate mismo — mala respuesta de API, timeout, permiso caído, todos salen con 1

Desde que lo shipeamos (medido sobre seis semanas):

47 pushes acoplados deployados limpio
3 pushes acoplados donde el gate cachó un deploy de backend fallido antes de que el frontend saliera (habría sido un outage visible para el usuario)
0 casos de gate haciendo false-proceed

Lo que NO ayudó

Intentar detectar "cambios de endpoint de API" desde el diff. Un cambio en un campo de schema de Pydantic basta), y los false negatives aquí son peores que los false positives. El check de path por git-diff es suficientemente bueno.
Cancel-in-progress en el workflow de frontend. Se ve atractivo matar el deploy de frontend en vuelo si llega un push nuevo — pero el cancel pasa a media S3-sync, dejando el bundle a medio subir. Combinado con un caché stale de CloudFront esto es peor que el race condition original. Lo dejamos en cancel-in-progress: false.

Qué sí ayudaría a futuro

Mover la lógica del gate a un action reutilizable (actions/wait-for-workflow@v1). Las ~80 líneas de bash funcionan pero están medio copy-pasteadas entre proyectos.
Sacar el conteo de pushes acoplados a un dashboard.** Si el ratio se va del 5% hacia el 30%, el gate simple deja de ser la herramienta correcta.
Hacer el deploy de backend más rápido para que la espera sea más corta cuando sí se active.

Lecciones

Los path filters definen qué cosas tus workflows acuerdan que los disparan. Mantenlos juntos y revísalos juntos.
El filtro head_sha en la API de Actions es lo más útil de todo esto. Existe, es estable, está documentado, y convierte "¿en cuál run estoy esperando?" de un problema difícil a un solo query.

Bajándole todos los minutos posibles al CI del backend con mas de 1000 tests

Franchesco Romero — Tue, 26 May 2026 05:11:47 +0000

Esta es la historia de muchas horas de trabajo en un hoyo continuo tratando de elegir optimizaciones entre package managers, caches, paralelismo, optimizaciones de PostgreSQL advisory locks, y el golpe de realidad de darme cuenta que el cuello de botella no era nada de lo que había estado optimizando, si no algo que no había analizado.

Antes de empezar aca esta el código disponible en Github para seguir paso a paso:

elchesco / improve-ci-times

improve-ci-times

Code companion — backend CI optimisation post

Stand-alone, copy-pasteable files for every code block in docs/blog-backend-ci-optimization.md.

Each folder maps to one round of the blog narrative:

00-starting-point/   the test job, Dockerfile, conftest before any work
01-uv/               drop pip for uv (Dockerfile + CI snippet)
02-buildkit/         BuildKit cache mounts + setup-buildx + --push
03-xdist-traps/      per-worker DB + DATABASE_URL alignment
04-template-db/      Postgres template DB + pg_advisory_lock
                     (plus the filelock dead-end as documentation)
05-diagnostic/       the measurement step that broke the assumption
06-final/            final shape — 4 matrix shards, no xdist, cumulative
                     Dockerfile + complete conftest

Notes

The xdist code (03, 04) is still present in 06-final/conftest.py for local pytest -n N runs even though the CI dropped xdist in favour of serial matrix shards.
04-template-db/filelock-attempt-DEAD-END.py is kept around…

View on GitHub

El punto de partida

El codebase:

un backend FastAPI (~50 routers, ~45 modelos SQLAlchemy)
1826 tests, desplegado vía GitHub Actions a AWS ECS Fargate en arm64.
El CI corre en un self-hosted spot runner (4X concurrencia, en Graviton).

En un inicio comenzamos con un paralelismo tradicional, nada del otro mundo, solo dos shards vía pytest-split.

# .github/workflows/deploy-backend.yml — inicial
- run: cd backend && pip install --cache-dir "$RUNNER_TEMP/pip-cache" -r requirements-dev.txt

- name: Tests (shard ${{ matrix.shard }}/2)
  run: |
    cd backend
    pytest tests/ \
      --splits 2 --group ${{ matrix.shard }} \
      --cov=app --cov-report= \
      -v

docker build estándar. Y usando pip para todo.

# backend/Dockerfile — inicial
FROM python:3.11-slim AS base
WORKDIR /app
RUN apt-get update && apt-get install -y --no-install-recommends \
    libpq-dev gcc curl \
    && rm -rf /var/lib/apt/lists/*
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

Intento no. 1: instalar dependencias más rápido con `uv`

uv es el reemplazo más sencillo que existe de pip creado por Astral, normalmente de 10x hasta 100× más rápido para resolver e instalar paquetes. La migración es bastante sencilla ya que son dos
líneas en el Dockerfile y listo:

# Pin vía la imagen multi-stage oficial para que el binario sea reproducible
COPY --from=ghcr.io/astral-sh/uv:0.5.11 /uv /uvx /usr/local/bin/
RUN uv pip install --system --no-cache-dir -r requirements.txt

requirements.txt y requirements-dev.txt quedan exactamente iguales, uv pip los lee nativo. No hay que migrar forzosamente a pyproject.toml.

Y en CI, le implementamos la action correspondiente:

- uses: astral-sh/setup-uv@v6
  with:
    version: "0.5.11"
    enable-cache: true
    cache-suffix: "shard-${{ matrix.shard }}"
- run: cd backend && uv pip install --system -r requirements-dev.txt

En este caso el cache-suffix por shard replica el workaround del --cache-dir por shard que teníamos con pip — sin él, los dos shards que caen en el mismo runner self-hosted se pelean por el mismo tarball y uno de los dos se muere con tar exit code 2.

La comparativa, en números:

$ time uv pip install -r requirements.txt
...
uv pip install -r requirements.txt  1.23s user 1.59s system 51% cpu 5.509 total

5.5s contra ~60s con pip y casi 80s en el runner.

Intento no. 2: BuildKit cache mounts en el Dockerfile

El layer cache de Docker solo ayuda cuando el COPY no invalida las
layers de abajo. Cualquier cambio en requirements.txt re construye
todo lo que sigue. Los BuildKit cache mounts ayudan a persistir el contenido entre builds sin importar la invalidación de layers:

# backend/Dockerfile — con cache mounts
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
    --mount=type=cache,target=/var/lib/apt,sharing=locked \
    apt-get update \
    && apt-get upgrade -y \
    && apt-get install -y --no-install-recommends \
        libpq-dev gcc curl

COPY requirements.txt .
RUN --mount=type=cache,target=/root/.cache/uv \
    uv pip install --system -r requirements.txt

Algo importante a mencionar:

Quitar el rm -rf /var/lib/apt/lists. Ya que servía para reducir el tamaño de la imagen, pero con cache mounts BuildKit es dueño de esos paths y los limpia entre builds sin hacer nada.
sharing=locked serializa lecturas concurrentes. Sin eso, dos builds en paralelo en el mismo runner pueden corromper el caché.

El runner que en este caso es self-hosted trae el builder legacy de Docker por default, y en el primer push después del commit de cache mounts se rompió con:

the --mount option requires BuildKit. Refer to
https://docs.docker.com/go/buildkit/ to learn how to build images with
BuildKit enabled

Lo arreglamos, de lo más fácil: instalar buildx y alias de docker build a docker buildx build:

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3
  with:
    install: true

El install: true es la opción necesaria. Sin eso, docker build sigue usando el builder legacy.

Buildx no carga al daemon local por default, así que el step de
docker push que ya teníamos también dejó de funcionar. Cambiamos a
--push directo:

- run: |
    cd backend
    docker build \
      --cache-from $IMAGE:latest \
      --cache-to type=inline \
      -t $IMAGE:sha-$TAG \
      -t $IMAGE:latest \
      --push \
      .

El --cache-to type=inline mete la metadata del layer cache dentro
de la imagen, cojn estoel --cache-from del siguiente build lo jala de regreso el ECR.

El primer build todavía viene con el costo de instalación de las dependencias y paquetes; los builds siguientes con los mismos requirements se lo brincan. Pasando de ~40s a ~10s en cache hits.

Intento no. 3: la trampa de `pytest-xdist`

El instinto es pensar que entre mas shards, podemos ahorrarnos mas tiempo, es decir 2 shards × 4 workers = 8 procesos en paralelo.

# backend/requirements-dev.txt
pytest-xdist==3.6.1

# .github/workflows/deploy-backend.yml
pytest tests/ \
  --splits 2 --group ${{ matrix.shard }} \
  -n 4 --dist worksteal \
  --cov=app --cov-report= \
  -v

Pero, es aquí es donde empieza el dilema.

Trampa 1: `DROP SCHEMA` entre workers

En mi configuración el conftest remueve y recrea el schema al inicio de cada session:

@pytest_asyncio.fixture(scope="session", autouse=True)
async def setup_db():
    async with test_engine.begin() as conn:
        await conn.execute(sa.text("DROP SCHEMA public CASCADE"))
        await conn.execute(sa.text("CREATE SCHEMA public"))
    async with test_engine.begin() as conn:
        await conn.run_sync(Base.metadata.create_all)

scope="session" significa una vez por session de pytest. Con
pytest-xdist, cada worker es su propia session.

Los cuatro workers apuntando a la misma DB myapp_test se la pasan removiendo el schema de los demás y en ocasiones nos quedamos a media corrida.

Fix: una DB por worker, con un sufijo de PYTEST_XDIST_WORKER:

def _suffix_dburl(url: str, worker: str) -> str:
    if "?" in url:
        url_part, _, query = url.partition("?")
        query = f"?{query}"
    else:
        url_part, query = url, ""
    if "/" not in url_part.split("@", 1)[-1]:
        return url
    prefix, dbname = url_part.rsplit("/", 1)
    return f"{prefix}/{dbname}_{worker}{query}"

_XDIST_WORKER = os.environ.get("PYTEST_XDIST_WORKER")
if _XDIST_WORKER:
    for key in ("DATABASE_URL", "TEST_DATABASE_URL"):
        if val := os.environ.get(key):
            os.environ[key] = _suffix_dburl(val, _XDIST_WORKER)

Con esto el worker gw0 agarra myapp_test_gw0, gw1 agarra _gw1, y así de manera secuencial.

Trampa 2: `max_locks_per_transaction`

Primera corrida con -n auto (10 workers en el runner self-hosted):

================== 31 passed, 11 warnings, 8 errors in 14.73s ==================

DROP SCHEMA CASCADE sobre ~50 tablas toma un relation-level lock por cada una.

10 workers x 50 = 500 locks.

El default de PostgreSQL para max_locks_per_transaction es 64.

Como lo arreglamos, bajamos el limite/cap a 4 workers por shard en vez de auto. 4 x 2 shards = 8 procesos paralelos.

Trampa 3: la divergencia del `DATABASE_URL`

Después de limitar a los workers, un test empezó a fallar en CI:

test_comp_expiry_worker_skips_stripe_managed
  sqlalchemy.exc.ProgrammingError: relation "subscriptions" does not
  exist

¿Por qué? El test invoca un background worker:

async def test_comp_expiry_worker_skips_stripe_managed(client, db, admin):
    member = await _seed_user(db, tier="TEST")
    sub = await _seed_sub(db, member, tier="TEST", ...)
    await db.commit()

    from app.workers.comp_expiry_worker import expire_comp_subscriptions
    await expire_comp_subscriptions()  # ← abre su propio AsyncSessionLocal

Fix: alinear DATABASE_URL con TEST_DATABASE_URL antes de que
app.main importe lo que sea:

# backend/tests/conftest.py — top del archivo, antes de importar app.main
_test_db = os.environ.get("TEST_DATABASE_URL")
if _test_db:
    os.environ["DATABASE_URL"] = _test_db

_XDIST_WORKER = os.environ.get("PYTEST_XDIST_WORKER")
if _XDIST_WORKER:
    for key in ("DATABASE_URL", "TEST_DATABASE_URL"):
        if val := os.environ.get(key):
            os.environ[key] = _suffix_dburl(val, _XDIST_WORKER)

from app.main import app  # ← engine construido con la URL correcta desde el inicio

Intento no. 4: template database de PostgreSQL

Cada worker todavía usa un DROP SCHEMA + CREATE TABLE × 50 al
inicio de la session.

En el runner ARM eso son ~5 segundos por worker.

PostgreSQL tiene un truco: CREATE DATABASE ... TEMPLATE
clona una DB vía copia a nivel de archivo en ~100ms en lugar de
ejecutar todo el SQL.

Construyes el schema una vez en una DB template dedicada, y luego cada worker la clona:

# backend/tests/conftest.py
TEMPLATE_DB_NAME = "myapp_test_template"
_TEMPLATE_LOCK_ID = 7321456789012345  # int arbitrario 

async def _ensure_template_db(admin_url: str, template_url: str) -> None:
    admin_engine = create_async_engine(
        admin_url, isolation_level="AUTOCOMMIT", poolclass=NullPool
    )
    try:
        async with admin_engine.connect() as conn:
            exists = (await conn.execute(
                sa.text("SELECT 1 FROM pg_database WHERE datname = :n"),
                {"n": TEMPLATE_DB_NAME},
            )).scalar_one_or_none()
            if not exists:
                await conn.execute(
                    sa.text(f'CREATE DATABASE "{TEMPLATE_DB_NAME}"')
                )
    finally:
        await admin_engine.dispose()

    tmpl_engine = create_async_engine(template_url, poolclass=NullPool)
    try:
        async with tmpl_engine.connect() as conn:
            has_schema = (await conn.execute(sa.text(
                "SELECT 1 FROM information_schema.tables "
                "WHERE table_schema = 'public' AND table_name = 'users' "
                "LIMIT 1"
            ))).scalar_one_or_none()
        if not has_schema:
            async with tmpl_engine.begin() as conn:
                await conn.run_sync(Base.metadata.create_all)
    finally:
        await tmpl_engine.dispose()


async def _clone_template_to(admin_url: str, dbname: str) -> None:
    admin_engine = create_async_engine(
        admin_url, isolation_level="AUTOCOMMIT", poolclass=NullPool
    )
    try:
        async with admin_engine.connect() as conn:
            # Matar conexiones stale para que el DROP no se bloquee
            await conn.execute(sa.text(
                "SELECT pg_terminate_backend(pid) FROM pg_stat_activity "
                "WHERE datname = :n AND pid <> pg_backend_pid()"
            ), {"n": dbname})
            await conn.execute(sa.text(f'DROP DATABASE IF EXISTS "{dbname}"'))
            await conn.execute(sa.text(
                f'CREATE DATABASE "{dbname}" TEMPLATE "{TEMPLATE_DB_NAME}"'
            ))
    finally:
        await admin_engine.dispose()

Trampa 4: `filelock` se cuelga

Los workers se pelean por crear el template. El primer intento usaba
filelock:

# No hagas esto
import filelock
lock = filelock.FileLock("/tmp/myapp_test_template.lock", timeout=120)
await asyncio.to_thread(lock.acquire)

Los workers consistentemente se quedan colgados y llegan a el timeout de 120s.

Con un cambio a un advisory lock de PostgreSQL, se soluciona. Es el mismo recurso compartido que ya necesitamos, se auto libera al cerrar la conexión:

async def _setup_db_via_template() -> None:
    split = _split_db_url(TEST_DATABASE_URL)
    if split is None:
        return
    prefix, dbname = split
    admin_url = f"{prefix}/postgres"
    template_url = f"{prefix}/{TEMPLATE_DB_NAME}"

    admin_engine = create_async_engine(
        admin_url, isolation_level="AUTOCOMMIT", poolclass=NullPool
    )
    try:
        async with admin_engine.connect() as conn:
            # Bloquea hasta conseguirlo; se auto-libera al cerrar la conexión
            await conn.execute(
                sa.text("SELECT pg_advisory_lock(:id)"),
                {"id": _TEMPLATE_LOCK_ID},
            )
            try:
                await _ensure_template_db(admin_url, template_url)
            finally:
                await conn.execute(
                    sa.text("SELECT pg_advisory_unlock(:id)"),
                    {"id": _TEMPLATE_LOCK_ID},
                )
    finally:
        await admin_engine.dispose()

    await _clone_template_to(admin_url, dbname)

El primer worker que agarra el lock construye el template (~5s); los demás esperan y luego clonan en ~100ms cada uno.

Después de todo esto tenemos DB por worker, alineación de DATABASE_URL, template clones, advisory locks — corriendo un smoke local de 7 archivos, notamos la diferencia:

88 passed, 5 warnings in 12.28s

Bajó de ~2 minutos con el setup inicial a unos cuantos segundos.

Intento no. 5: la medición que rompió el supuesto

El wall time por shard seguía como en 7 minutos.
El CI total en 11m una mejora modesta sobre el baseline inicial, pero no la bajada dramática que sugería el smoke local.

Hora de medir en serio.
Agregué un step diagnóstico que corre una vez y reporta tiempos:

- name: Diagnose pytest startup cost
  if: matrix.shard == 1
  run: |
    cd backend
    echo "::group::A — solo collection de pytest, sin coverage"
    time pytest tests/ --co -q --no-header --no-cov
    echo "::endgroup::"
    echo "::group::B — solo collection de pytest CON coverage"
    time pytest tests/ --co -q --no-header --cov=app --cov-report=
    echo "::endgroup::"
    echo "::group::C — corrida chiquita serial, sin coverage, sin xdist"
    time pytest tests/test_critical.py -q --no-header --no-cov
    echo "::endgroup::"

Los resultados en el runner ARM self-hosted fueron:

A — solo collection, sin coverage          real    0m18.909s
B — solo collection CON coverage           real    0m23.810s
C — corrida chica serial, sin nada         real    0m21.481s

La observación clave, hacer collection de 1826 tests y
correr un solo archivo chico sin coverage tardan lo mismo.

O sea, el costo no es la collection.
No es coverage (solo 5s de diferencia).
No es la ejecución de los tests.
Es el startup de pytest + el import del conftest.
Específicamente el from app.main import app en el conftest que jala ~45 modelos, ~50 routers, middleware, settings, todo de un jalón. Veinte segundos de cold import en este runner.

Cada vez.

Con xdist, cada uno de los 4 workers paga este costo de 20s
independiente.

Ahí estaban los ~80s perdidos.

Round 6: soltar `xdist`, irse a 4 shards

Si cada proceso de pytest usa 20s fijos de startup, la optimización
más barata es usarlo menos veces.
2 shards X 4 workers de xdist = 10 startups de pytest (2 controllers + 8 workers).
4 shards X 1 proceso serial = 4 startups de pytest.

test:
  runs-on: ${{ inputs.runner || 'self-hosted' }}
  needs: lint
  strategy:
    fail-fast: false
    matrix:
      shard: [1, 2, 3, 4]
  services:
    postgres:
      image: postgres:15
      env: { POSTGRES_DB: myapp_test, POSTGRES_USER: appuser, POSTGRES_PASSWORD: testpass }
      options: >-
        --health-cmd pg_isready --health-interval 10s
        --health-timeout 5s --health-retries 5
      ports: ["5432"]
  steps:
    - uses: actions/checkout@v5
    - uses: actions/setup-python@v6
      with: { python-version: "3.11" }
    - uses: astral-sh/setup-uv@v6
      with:
        version: "0.5.11"
        enable-cache: true
        cache-suffix: "shard-${{ matrix.shard }}"
    - run: cd backend && uv pip install --system -r requirements-dev.txt
    - name: Tests (shard ${{ matrix.shard }}/4)
      env:
        DATABASE_URL: postgresql://someappuser:sometestpass@localhost:${{ job.services.postgres.ports[5432] }}/myapp_test
        TEST_DATABASE_URL: postgresql+asyncpg://someappuser:sometestpass@localhost:${{ job.services.postgres.ports[5432] }}/myapp_test
        SECRET_KEY: ci-test-secret-key-32bytes-minimum-length
        ENV: test
        COVERAGE_FILE: .coverage.${{ matrix.shard }}
      run: |
        cd backend
        pytest tests/ \
          --splits 4 --group ${{ matrix.shard }} \
          --cov=app --cov-report= \
          -q --no-header

Cada shard corre ~450 tests en serial con un solo proceso de pytest.

Sin fan-out de xdist, sin re-import de conftest por worker, sin temas de CPU en los cold imports.

El runner self-hosted anuncia 4X de concurrencia disponible, así que los cuatro shards corren en paralelo.

El coverage se extiende a cuatro archivos:

coverage:
  needs: test
  steps:
    - uses: actions/checkout@v5
    - uses: actions/setup-python@v6
      with: { python-version: "3.11" }
    - uses: astral-sh/setup-uv@v6
      with: { version: "0.5.11" }
    - run: uv pip install --system coverage==7.6.1
    - uses: actions/download-artifact@v5
      with:
        pattern: coverage-*
        path: backend/
        merge-multiple: true
    - run: |
        cd backend
        coverage combine .coverage.1 .coverage.2 .coverage.3 .coverage.4
        coverage report --fail-under=60

También quité el -v y lo cambié por -q --no-header. Con xdist, el -v bufferea el output por worker hasta que termina un test, -q tiene output instantáneo y muestra la salida de inmediato.

El resultado

Corrida real del CI después del push:

✓ lint              in 1m6s
✓ test (1)          in 6m46s
✓ test (2)          in 6m44s
✓ test (3)          in 6m57s
✓ test (4)          in 6m57s
✓ coverage          in 10s
✓ build-and-deploy  in 1m53s

Timeline del test step del shard 1:

16:31:44  inicio del step
16:32:57  [pytest-split] Running group 1/4   ← 1m13s adentro
16:33:25  ........... [ 15%]                  ← primer punto a 1m41s
16:34:18  ........... [ 45%]
16:37:04  ........... [ 91%]
16:37:47  ........... [100%]  472 passed in 5m21s

Tiempo al primer output: 1m13s vs 2m37s antes.
Más o menos a la mitad.

CI total: 10m16s vs ~20m del baseline antes de cualquier optimización.

Otras cosas que probe y que definitivamente no ayudaron

Precompile de pyc (python -m compileall). Medición local: 13.0s en frío vs 12.6s en caliente.
pytest-xdist --dist worksteal está bueno cuando cada worker tiene un costo de setup parecido. Cuando el setup es ~20s y los tests son mayormente rápidos, el impuesto de startup por worker se come la ganancia de paralelismo.
filelock para serializar entre procesos. No me serializaba bien los workers en mi setup. Me cambié a advisory locks de PG.
El flag -v. Causaba 2 minutos de buffering de output bajo xdist sin beneficio en performance.

Qué sí ayudaría a futuro

Mejorar el conftest. El from app.main import app es el costo más grande en mi caso. La app importa cada router, cada modelo, cada service al arranque. Partirla (lazy router registration, o romper el import monolítico) bajaría a 20s de startup.
Una segunda pasada en los shards. pytest-split balancea por duración. Si un shard consistentemente va 30s atrás, re-balancea:

   pytest --splits 4 --group 1 --store-durations

comitea un .test_durations nuevo contra el que los futuros runs
se balancean.

Sacar coverage del hot path. Coverage solo agregó ~5s en ARM en nuestro benchmark, pero a ~5s × 4 shards = 20s ahorrados. Trade-off: o lo aceptas en el job de tests o agregas un job de coverage no-paralelo aparte. Nosotros lo dejamos en el path.

Lecciones

Mide antes de optimizar. Varias horas de trabajo en xdist, template DBs y BuildKit fueron útiles, pero el verdadero unlock vino de un step diagnóstico de 30 segundos que me dijo que el cuello de botella era el startup de pytest, no nada de lo que llevaba atacando.
El pytest más rápido es uno que no inicias dos veces. Cada invocación de pytest paga un costo de startup fijo. Con un conftest pesado, ese costo domina todo lo demás. Más paralelismo = más startups = más costo. Menos shards más grandes le ganan a más shards chiquitos pasado un umbral.
pytest-xdist no es gratis. Funciona bien cuando el costo por test >> el costo de startup. Cuando el startup es 20s y los tests son de 500ms, la ecuación se invierte.
Recursos por worker necesitan aislamiento por worker. El bug sutil fue que los background workers abrían su propio AsyncSessionLocal apuntando a la DB equivocada. El fix no estaba en la aplicación — estaba en el conftest de tests, alineando las env vars antes de que la app importara nada.
PostgreSQL tiene las primitivas. Advisory locks para sincronizar entre procesos, CREATE DATABASE ... TEMPLATE para bootstrap de schema. Las dos me salvaron de inventar mecanismos más débiles encima.
Los BuildKit cache mounts siguen sub-utilizados. Dos líneas en un Dockerfile (--mount=type=cache para los cachés de apt y uv/pip) bajaron los docker builds repetidos de ~40s a ~10s, pero solo después de cambiarse del builder legacy de Docker vía setup-buildx-action.

Código completo disponible en Github:

elchesco / improve-ci-times

improve-ci-times

Code companion — backend CI optimisation post

Stand-alone, copy-pasteable files for every code block in docs/blog-backend-ci-optimization.md.

Each folder maps to one round of the blog narrative:

00-starting-point/   the test job, Dockerfile, conftest before any work
01-uv/               drop pip for uv (Dockerfile + CI snippet)
02-buildkit/         BuildKit cache mounts + setup-buildx + --push
03-xdist-traps/      per-worker DB + DATABASE_URL alignment
04-template-db/      Postgres template DB + pg_advisory_lock
                     (plus the filelock dead-end as documentation)
05-diagnostic/       the measurement step that broke the assumption
06-final/            final shape — 4 matrix shards, no xdist, cumulative
                     Dockerfile + complete conftest

Notes

The xdist code (03, 04) is still present in 06-final/conftest.py for local pytest -n N runs even though the CI dropped xdist in favour of serial matrix shards.
04-template-db/filelock-attempt-DEAD-END.py is kept around…

View on GitHub

Bajándole todos los minutos posibles al CI del backend con mas de 1000 tests

Franchesco Romero — Tue, 26 May 2026 05:11:47 +0000

Esta es la historia de muchas horas de trabajo en un hoyo continuo tratando de elegir optimizaciones entre package managers, caches paralelismo, optimizaciones de PostgreSQL, advisory locks, y el golpe de realidad de darme cuenta que el cuello de botella no era nada de lo que había estado optimizando, si no algo que no había analizado.

El punto de partida

El codebase: un backend FastAPI (~50 routers, ~45 modelos SQLAlchemy)
con 1826 tests, desplegado vía GitHub Actions a AWS ECS Fargate en
arm64. El CI corre en un self-hosted spot runner (4× concurrency,
Graviton).

En un inicio comenzamos con un paralelismo tradicional, nada del otro mundo, solo dos shards vía pytest-split.

# .github/workflows/deploy-backend.yml — inicial
- run: cd backend && pip install --cache-dir "$RUNNER_TEMP/pip-cache" -r requirements-dev.txt

- name: Tests (shard ${{ matrix.shard }}/2)
  run: |
    cd backend
    pytest tests/ \
      --splits 2 --group ${{ matrix.shard }} \
      --cov=app --cov-report= \
      -v

docker build estándar. Y usando pip para todo.

# backend/Dockerfile — inicial
FROM python:3.11-slim AS base
WORKDIR /app
RUN apt-get update && apt-get install -y --no-install-recommends \
    libpq-dev gcc curl \
    && rm -rf /var/lib/apt/lists/*
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

Intento no. 1: instalar dependencias más rápido con uv

# Pin vía la imagen multi-stage oficial para que el binario sea reproducible
COPY --from=ghcr.io/astral-sh/uv:0.5.11 /uv /uvx /usr/local/bin/
RUN uv pip install --system --no-cache-dir -r requirements.txt

requirements.txt y requirements-dev.txt quedan exactamente iguales, uv pip los lee nativo. No hay que migrar forzosamente a pyproject.toml.

Y en CI, le implementamos la action correspondiente:

- uses: astral-sh/setup-uv@v6
  with:
    version: "0.5.11"
    enable-cache: true
    cache-suffix: "shard-${{ matrix.shard }}"
- run: cd backend && uv pip install --system -r requirements-dev.txt

La comparativa, en números:

$ time uv pip install -r requirements.txt
...
uv pip install -r requirements.txt  1.23s user 1.59s system 51% cpu 5.509 total

5.5s contra ~60s con pip y casi 80s en el runner.

Intento no. 2: BuildKit cache mounts en el Dockerfile

El layer cache de Docker solo ayuda cuando el COPY no invalida las
layers de abajo. Cualquier cambio en requirements.txt re-construye
todo lo que sigue. Los BuildKit cache mounts ayudan a persistir el contenido entre builds sin importar la invalidación de layers:

# backend/Dockerfile — con cache mounts
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
    --mount=type=cache,target=/var/lib/apt,sharing=locked \
    apt-get update \
    && apt-get upgrade -y \
    && apt-get install -y --no-install-recommends \
        libpq-dev gcc curl

COPY requirements.txt .
RUN --mount=type=cache,target=/root/.cache/uv \
    uv pip install --system -r requirements.txt

Algo importante a mencionar:

Quitar el rm -rf /var/lib/apt/lists. Ya que servía para reducir el tamaño de la imagen, pero con cache mounts BuildKit es dueño de esos paths y los limpia entre builds.
sharing=locked serializa lecturas concurrentes. Sin eso, dos builds en paralelo en el mismo runner pueden corromper el caché.

El runner que en este caso es self-hosted trae el builder legacy de Docker por default, y el primer push después del commit de cache mounts se murió con:

the --mount option requires BuildKit. Refer to
https://docs.docker.com/go/buildkit/ to learn how to build images with
BuildKit enabled

Lo arreglamos, de lo más fácil: instalar buildx y alias de docker build a docker buildx build:

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3
  with:
    install: true

El install: true es la opción crítica. Sin eso, docker build sigue usando el builder legacy.

Buildx no carga al daemon local por default, así que el step de
docker push que ya teníamos también dejó de funcionar. Cambio a
--push directo:

- run: |
    cd backend
    docker build \
      --cache-from $IMAGE:latest \
      --cache-to type=inline \
      -t $IMAGE:sha-$TAG \
      -t $IMAGE:latest \
      --push \
      .

El --cache-to type=inline mete la metadata del layer cache dentro
de la imagen, cojn estoel --cache-from del siguiente build lo jala de regreso el ECR.

El primer build todavía paga el costo de instalación de las dependencias y paquetes; los builds siguientes con los mismos requirements se lo brincan. Pasando de ~40s a ~10s en cache hits.

Intento no. 3: la trampa de `pytest-xdist`

El instinto, pensar que entre mas shards, podemos ahorrarnos mas tiempo, es decir 2 shards × 4 workers = 8 procesos en paralelo.

# backend/requirements-dev.txt
pytest-xdist==3.6.1

# .github/workflows/deploy-backend.yml
pytest tests/ \
  --splits 2 --group ${{ matrix.shard }} \
  -n 4 --dist worksteal \
  --cov=app --cov-report= \
  -v

Aquí es donde empieza el dilema.

Trampa 1: `DROP SCHEMA` entre workers

El conftest remueve y recrea el schema al inicio de cada session:

@pytest_asyncio.fixture(scope="session", autouse=True)
async def setup_db():
    async with test_engine.begin() as conn:
        await conn.execute(sa.text("DROP SCHEMA public CASCADE"))
        await conn.execute(sa.text("CREATE SCHEMA public"))
    async with test_engine.begin() as conn:
        await conn.run_sync(Base.metadata.create_all)

scope="session" significa una vez por session de pytest. Con
pytest-xdist, cada worker es su propia session.

Los cuatro workers apuntando a la misma DB myapp_test se la pasan removiendo el schema de los demás a media corrida.

Fix: una DB por worker, con sufijo de PYTEST_XDIST_WORKER:

def _suffix_dburl(url: str, worker: str) -> str:
    if "?" in url:
        url_part, _, query = url.partition("?")
        query = f"?{query}"
    else:
        url_part, query = url, ""
    if "/" not in url_part.split("@", 1)[-1]:
        return url
    prefix, dbname = url_part.rsplit("/", 1)
    return f"{prefix}/{dbname}_{worker}{query}"

_XDIST_WORKER = os.environ.get("PYTEST_XDIST_WORKER")
if _XDIST_WORKER:
    for key in ("DATABASE_URL", "TEST_DATABASE_URL"):
        if val := os.environ.get(key):
            os.environ[key] = _suffix_dburl(val, _XDIST_WORKER)

El worker gw0 agarra myapp_test_gw0, gw1 agarra _gw1, y así de manera secuencial.

Trampa 2: `max_locks_per_transaction`

Primera corrida con -n auto (10 workers en el runner self-hosted):

================== 31 passed, 11 warnings, 8 errors in 14.73s ==================

DROP SCHEMA CASCADE sobre ~50 tablas toma un relation-level lock por cada una.

10 workers × 50 = 500 locks.

El default de PostgreSQL para max_locks_per_transaction es 64

Como lo arreglamos, bajamos el limite/cap a 4 workers por shard en vez de auto. 4 × 2 shards = 8 procesos paralelos.

Trampa 3: la divergencia del `DATABASE_URL`

Después de limitar a los workers, un test empezó a fallar en CI:

test_comp_expiry_worker_skips_stripe_managed
  sqlalchemy.exc.ProgrammingError: relation "subscriptions" does not
  exist

¿Por qué? El test invoca un background worker:

async def test_comp_expiry_worker_skips_stripe_managed(client, db, admin):
    member = await _seed_user(db, tier="TEST")
    sub = await _seed_sub(db, member, tier="TEST", ...)
    await db.commit()

    from app.workers.comp_expiry_worker import expire_comp_subscriptions
    await expire_comp_subscriptions()  # ← abre su propio AsyncSessionLocal

Fix: alinear DATABASE_URL con TEST_DATABASE_URL antes de que
app.main importe lo que sea:

# backend/tests/conftest.py — top del archivo, antes de importar app.main
_test_db = os.environ.get("TEST_DATABASE_URL")
if _test_db:
    os.environ["DATABASE_URL"] = _test_db

_XDIST_WORKER = os.environ.get("PYTEST_XDIST_WORKER")
if _XDIST_WORKER:
    for key in ("DATABASE_URL", "TEST_DATABASE_URL"):
        if val := os.environ.get(key):
            os.environ[key] = _suffix_dburl(val, _XDIST_WORKER)

from app.main import app  # ← engine construido con la URL correcta desde el inicio

Intento no. 4: template database de PostgreSQL

Cada worker todavía usa un DROP SCHEMA + CREATE TABLE × 50 al
inicio de la session.
En el runner ARM eso son ~5 segundos por worker.

PostgreSQL tiene un truco: CREATE DATABASE ... TEMPLATE
clona una DB vía copia a nivel de archivo en ~100ms en lugar de
ejecutar todo el SQL.

Construyes el schema una vez en una DB template dedicada, y luego cada worker la clona:

# backend/tests/conftest.py
TEMPLATE_DB_NAME = "myapp_test_template"
_TEMPLATE_LOCK_ID = 7321456789012345  # int arbitrario 

async def _ensure_template_db(admin_url: str, template_url: str) -> None:
    admin_engine = create_async_engine(
        admin_url, isolation_level="AUTOCOMMIT", poolclass=NullPool
    )
    try:
        async with admin_engine.connect() as conn:
            exists = (await conn.execute(
                sa.text("SELECT 1 FROM pg_database WHERE datname = :n"),
                {"n": TEMPLATE_DB_NAME},
            )).scalar_one_or_none()
            if not exists:
                await conn.execute(
                    sa.text(f'CREATE DATABASE "{TEMPLATE_DB_NAME}"')
                )
    finally:
        await admin_engine.dispose()

    tmpl_engine = create_async_engine(template_url, poolclass=NullPool)
    try:
        async with tmpl_engine.connect() as conn:
            has_schema = (await conn.execute(sa.text(
                "SELECT 1 FROM information_schema.tables "
                "WHERE table_schema = 'public' AND table_name = 'users' "
                "LIMIT 1"
            ))).scalar_one_or_none()
        if not has_schema:
            async with tmpl_engine.begin() as conn:
                await conn.run_sync(Base.metadata.create_all)
    finally:
        await tmpl_engine.dispose()


async def _clone_template_to(admin_url: str, dbname: str) -> None:
    admin_engine = create_async_engine(
        admin_url, isolation_level="AUTOCOMMIT", poolclass=NullPool
    )
    try:
        async with admin_engine.connect() as conn:
            # Matar conexiones stale para que el DROP no se bloquee
            await conn.execute(sa.text(
                "SELECT pg_terminate_backend(pid) FROM pg_stat_activity "
                "WHERE datname = :n AND pid <> pg_backend_pid()"
            ), {"n": dbname})
            await conn.execute(sa.text(f'DROP DATABASE IF EXISTS "{dbname}"'))
            await conn.execute(sa.text(
                f'CREATE DATABASE "{dbname}" TEMPLATE "{TEMPLATE_DB_NAME}"'
            ))
    finally:
        await admin_engine.dispose()

Trampa 4: `filelock` se cuelga

Los workers se pelean por crear el template. El primer intento usaba
filelock:

# No hagas esto
import filelock
lock = filelock.FileLock("/tmp/myapp_test_template.lock", timeout=120)
await asyncio.to_thread(lock.acquire)

Los workers consistentemente llegan a el timeout de 120s.

Con un cambio a un advisory lock de PostgreSQL, se soluciona. Es el mismo recurso compartido que ya necesitamos, se auto libera al cerrar la conexión (así que un worker que truene no puede dejar el lock huérfano como pasa con file locks):

async def _setup_db_via_template() -> None:
    split = _split_db_url(TEST_DATABASE_URL)
    if split is None:
        return
    prefix, dbname = split
    admin_url = f"{prefix}/postgres"
    template_url = f"{prefix}/{TEMPLATE_DB_NAME}"

    admin_engine = create_async_engine(
        admin_url, isolation_level="AUTOCOMMIT", poolclass=NullPool
    )
    try:
        async with admin_engine.connect() as conn:
            # Bloquea hasta conseguirlo; se auto-libera al cerrar la conexión
            await conn.execute(
                sa.text("SELECT pg_advisory_lock(:id)"),
                {"id": _TEMPLATE_LOCK_ID},
            )
            try:
                await _ensure_template_db(admin_url, template_url)
            finally:
                await conn.execute(
                    sa.text("SELECT pg_advisory_unlock(:id)"),
                    {"id": _TEMPLATE_LOCK_ID},
                )
    finally:
        await admin_engine.dispose()

    await _clone_template_to(admin_url, dbname)

El primer worker que agarra el lock construye el template (~5s); los demás esperan y luego clonan en ~100ms cada uno.

Después de todo esto — DBs por worker, alineación de DATABASE_URL,
template clones, advisory locks — corriendo un smoke local de 7
archivos:

88 passed, 5 warnings in 12.28s

Bajó de ~2 minutos con el setup roto inicial de xdist.

Intento no. 5: la medición que rompió el supuesto

El wall time por shard seguía como en 7 minutos.
El CI total en 11m una mejora modesta sobre el baseline, no la bajada dramática que sugería el smoke local.

Hora de medir en serio. Agregué un step diagnóstico que corre una vez
y reporta tiempos:

- name: Diagnose pytest startup cost
  if: matrix.shard == 1
  run: |
    cd backend
    echo "::group::A — solo collection de pytest, sin coverage"
    time pytest tests/ --co -q --no-header --no-cov
    echo "::endgroup::"
    echo "::group::B — solo collection de pytest CON coverage"
    time pytest tests/ --co -q --no-header --cov=app --cov-report=
    echo "::endgroup::"
    echo "::group::C — corrida chiquita serial, sin coverage, sin xdist"
    time pytest tests/test_critical.py -q --no-header --no-cov
    echo "::endgroup::"

Los resultados en el runner ARM self-hosted fueron:

A — solo collection, sin coverage          real    0m18.909s
B — solo collection CON coverage           real    0m23.810s
C — corrida chica serial, sin nada         real    0m21.481s

La observación clave, hacer collection de 1826 tests y
correr un solo archivo chico sin coverage tardan lo mismo.

O sea, el costo no es la collection. No es coverage (solo 5s de
diferencia).
No es la ejecución de los tests. Es el startup de pytest + el import del conftest.
Específicamente el from app.main import app en el conftest que jala ~45 modelos, ~50 routers, middleware, settings — todo de un jalón. Veinte segundos de cold-import en este runner.
Cada vez.

Con xdist, cada uno de los 4 workers paga este costo de 20s
independiente. Spawn en paralelo, pero el runner solo tiene ciertos
cores; los cold imports de modelos pydantic y mappers de SQLAlchemy se pelean por CPU.

Ahí estaban los ~80s perdidos.

Round 6: soltar `xdist`, irse a 4 shards

Si cada proceso de pytest usa 20s fijos de startup, la optimización
más barata es usarlo menos veces.
2 shards × 4 workers de xdist = 10 startups de pytest (2 controllers + 8 workers).
4 shards × 1 proceso serial = 4 startups de pytest.

test:
  runs-on: ${{ inputs.runner || 'self-hosted' }}
  needs: lint
  strategy:
    fail-fast: false
    matrix:
      shard: [1, 2, 3, 4]
  services:
    postgres:
      image: postgres:15
      env: { POSTGRES_DB: myapp_test, POSTGRES_USER: appuser, POSTGRES_PASSWORD: testpass }
      options: >-
        --health-cmd pg_isready --health-interval 10s
        --health-timeout 5s --health-retries 5
      ports: ["5432"]
  steps:
    - uses: actions/checkout@v5
    - uses: actions/setup-python@v6
      with: { python-version: "3.11" }
    - uses: astral-sh/setup-uv@v6
      with:
        version: "0.5.11"
        enable-cache: true
        cache-suffix: "shard-${{ matrix.shard }}"
    - run: cd backend && uv pip install --system -r requirements-dev.txt
    - name: Tests (shard ${{ matrix.shard }}/4)
      env:
        DATABASE_URL: postgresql://someappuser:sometestpass@localhost:${{ job.services.postgres.ports[5432] }}/myapp_test
        TEST_DATABASE_URL: postgresql+asyncpg://someappuser:sometestpass@localhost:${{ job.services.postgres.ports[5432] }}/myapp_test
        SECRET_KEY: ci-test-secret-key-32bytes-minimum-length
        ENV: test
        COVERAGE_FILE: .coverage.${{ matrix.shard }}
      run: |
        cd backend
        pytest tests/ \
          --splits 4 --group ${{ matrix.shard }} \
          --cov=app --cov-report= \
          -q --no-header

Cada shard corre ~450 tests en serial con un solo proceso depytest.

Sin fan-out de xdist, sin re-import de conftest por worker, sin contención de CPU en los cold imports.

El runner self-hosted anuncia 4x de concurrencia disponible, así que los cuatro shards corren en paralelo.

El coverage se extiende a cuatro archivos:

coverage:
  needs: test
  steps:
    - uses: actions/checkout@v5
    - uses: actions/setup-python@v6
      with: { python-version: "3.11" }
    - uses: astral-sh/setup-uv@v6
      with: { version: "0.5.11" }
    - run: uv pip install --system coverage==7.6.1
    - uses: actions/download-artifact@v5
      with:
        pattern: coverage-*
        path: backend/
        merge-multiple: true
    - run: |
        cd backend
        coverage combine .coverage.1 .coverage.2 .coverage.3 .coverage.4
        coverage report --fail-under=60

El resultado

Corrida real del CI después del push:

✓ lint              in 1m6s
✓ test (1)          in 6m46s
✓ test (2)          in 6m44s
✓ test (3)          in 6m57s
✓ test (4)          in 6m57s
✓ coverage          in 10s
✓ build-and-deploy  in 1m53s

Timeline del test step del shard 1:

16:31:44  inicio del step
16:32:57  [pytest-split] Running group 1/4   ← 1m13s adentro
16:33:25  ........... [ 15%]                  ← primer punto a 1m41s
16:34:18  ........... [ 45%]
16:37:04  ........... [ 91%]
16:37:47  ........... [100%]  472 passed in 5m21s

Tiempo al primer output: 1m13s vs 2m37s antes.
Más o menos a la mitad.

CI total: 10m16s vs ~20m del baseline antes de cualquier optimización.

Otras cosas que probe y que definitivamente no ayudaron

Precompile de pyc (python -m compileall). Medición local: 13.0s en frío vs 12.6s en caliente.
pytest-xdist --dist worksteal está bueno cuando cada worker tiene un costo de setup parecido. Cuando el setup es ~20s y los tests son mayormente rápidos, el impuesto de startup por worker se come la ganancia de paralelismo.
filelock para serializar entre procesos. No me serializaba bien los workers en mi setup. Me cambié a advisory locks de PG.
El flag -v. Causaba 2 minutos de buffering de output bajo xdist sin beneficio en performance.

Qué sí ayudaría a futuro

Mejorar el conftest. El from app.main import app es el costo más grande en mi caso. La app importa cada router, cada modelo, cada service al arranque. Partirla (lazy router registration, o romper el import monolítico) bajaría a 20s de startup.
Una segunda pasada en los shards. pytest-split balancea por duración. Si un shard consistentemente va 30s atrás, re-balancea:

   pytest --splits 4 --group 1 --store-durations

comitea un .test_durations nuevo contra el que los futuros runs
se balancean.

Sacar coverage del hot path. Coverage solo agregó ~5s en ARM en nuestro benchmark, pero a ~5s × 4 shards = 20s ahorrados. Trade-off: o lo aceptas en el job de tests o agregas un job de coverage no-paralelo aparte. Nosotros lo dejamos en el path.

Lecciones

Mide antes de optimizar. Varias horas de trabajo en xdist, template DBs y BuildKit fueron útiles, pero el verdadero unlock vino de un step diagnóstico de 30 segundos que me dijo que el cuello de botella era el startup de pytest, no nada de lo que llevaba atacando.
El pytest más rápido es uno que no inicias dos veces. Cada invocación de pytest paga un costo de startup fijo. Con un conftest pesado, ese costo domina todo lo demás. Más paralelismo = más startups = más costo. Menos shards más grandes le ganan a más shards chiquitos pasado un umbral.
pytest-xdist no es gratis. Funciona bien cuando el costo por test >> el costo de startup. Cuando el startup es 20s y los tests son de 500ms, la ecuación se invierte.
Recursos por worker necesitan aislamiento por worker. El bug sutil fue que los background workers abrían su propio AsyncSessionLocal apuntando a la DB equivocada. El fix no estaba en la aplicación — estaba en el conftest de tests, alineando las env vars antes de que la app importara nada.
PostgreSQL tiene las primitivas. Advisory locks para sincronizar entre procesos, CREATE DATABASE ... TEMPLATE para bootstrap de schema. Las dos me salvaron de inventar mecanismos más débiles encima.
Los BuildKit cache mounts siguen sub-utilizados. Dos líneas en un Dockerfile (--mount=type=cache para los cachés de apt y uv/pip) bajaron los docker builds repetidos de ~40s a ~10s, pero solo después de cambiarse del builder legacy de Docker vía setup-buildx-action.

Pros y Cons de las arquitecturas multi-región

Franchesco Romero — Thu, 02 Apr 2026 22:07:40 +0000

Pros y Cons de las arquitecturas multi-región - Speaker Deck

speakerdeck.com

Los retos reales de ir multi-región

Antes de hablar de soluciones, hay que nombrar los retos con claridad porque es donde más se subestima el esfuerzo. El primero es elegir la solución tecnológica correcta — no todas las cargas de trabajo necesitan multi-región y no todos los servicios de AWS están disponibles igual en todas las regiones. El segundo es el manejo de fallos a escala: no basta con tener recursos en dos regiones si no has pensado cómo se comporta cada componente ante una falla. El tercero es la cercanía a los usuarios, que no siempre es puramente técnica — hay leyes, regulaciones y requisitos de soberanía de datos que dictan dónde puede vivir tu información.

Ignorar cualquiera de estos puntos al inicio garantiza una conversación mucho más difícil después.

Tolerancia a fallos: el modelo mental que todo lo rige

El concepto clave aquí es el dominio de error (fault domain). Cada componente de tu arquitectura pertenece a un dominio que define su política de falla: puede ser redundante (se replica), ignorable (su caída no afecta el sistema), o en cascada (si cae, arrastra a quien depende de él — el temido SPOF).

El problema clásico es una arquitectura donde la base de datos es un dominio en cascada dentro de una sola AZ, en una sola región. Si esa AZ tiene problemas, caes completo. La estrategia multi-región resuelve esto añadiendo un nivel más en la jerarquía de dominios, pero también introduce nuevas preguntas sobre consistencia y latencia de replicación que hay que responder explícitamente.

Las capas de una arquitectura multi-región

Pensar en capas ayuda a no perderse. Cada capa tiene sus propias decisiones y sus propios servicios.

Capa de redes. El CDN entrega contenido global con acceso seguro y rápido — CloudFront es el componente natural aquí en AWS. El DNS, específicamente Route 53, es quien realmente orquesta el tráfico entre regiones: puedes rutear por latencia, por failover, por geolocalización o con políticas ponderadas. Una buena estrategia de DNS hace más diferencia de lo que la gente espera — es literalmente el primer punto de decisión que toca cada request de usuario. Las redes internas entre regiones deben estar interconectadas y planificadas desde el inicio, no como un afterthought.

Capa de cómputo. Los servicios deben ser modulares, organizados por dominio de negocio y escalables bajo demanda. La elección entre Lambda, EC2, ECS o Kubernetes depende del caso de uso — no hay respuesta genérica, y lo que sí aplica siempre es que la capa de cómputo debe poder replicarse o levantarse en otra región sin fricción manual.

Capa de aplicación. Aquí hay un principio que marca la diferencia: la aplicación debe ser agnóstica a la región. Eso implica configuración externalizada, procesos sin estado (stateless) y secretos administrables. Un ejemplo concreto: leer el region_name desde una variable en lugar de hardcodearlo en el código. Suena básico y sin embargo es donde se rompen más arquitecturas multi-región en la práctica.

Capa de datos. Esta es la más compleja. Antes de elegir un servicio hay que identificar los patrones de acceso, el tipo de almacenamiento (bloque, archivo u objeto), el costo de replicación y dónde están los usuarios. AWS tiene soporte de replicación cross-region en DynamoDB, RDS Aurora, RDS estándar, S3, ElastiCache y DocumentDB. Cada uno tiene sus propias implicaciones de consistencia eventual vs. consistencia fuerte que hay que entender antes de decidir.

Capa de seguridad, identidad y acceso. IAM es global, lo cual simplifica la gestión de usuarios, roles y grupos. KMS permite crear llaves con capacidad multi-región. Secrets Manager puede replicar secretos en regiones secundarias — y aquí hay un detalle importante de Terraform: cuando configuras un aws_secretsmanager_secret con un bloque replica, la región secundaria se sincroniza automáticamente. Parece trivial hasta que lo necesitas en un failover real.

Monitoreo: no es opcional, es parte de la arquitectura

Una arquitectura multi-región sin observabilidad centralizada es básicamente una caja negra distribuida. CloudWatch, Config, GuardDuty y CloudTrail son servicios regionales, pero servicios como Security Hub y CloudTrail soportan agregados multi-región, lo que permite tener una vista unificada de eventos de seguridad sin tener que revisar consola por consola.

Hay un punto importante aquí: una estrategia de monitoreo requiere varias iteraciones. No sale perfecta a la primera. Herramientas como Amazon DevOps Guru ayudan a identificar comportamientos anómalos, sugerir mejoras de configuración y alertar sobre fallos críticos — complementan bien el stack base de observabilidad.

Despliegue: IaC o no escala

En arquitecturas multi-región, el despliegue manual no es una opción viable a largo plazo. Infraestructura como código (Terraform, CDK, CloudFormation) no es solo una buena práctica — es lo que permite recrear un entorno completo en otra región en minutos en lugar de días. El control de cambios debe ser granular: por cuenta, por ambiente y por región. IAM debe seguir el principio de mínimo privilegio, y los fallos deben estar controlados — es decir, un error en el despliegue de una región no debe tumbar las otras.

Un tip práctico: las nuevas regiones también funcionan muy bien como sandbox para validar nuevas funcionalidades o para simular desastres antes de que lleguen solos.

Lo que realmente hay que considerar antes de empezar

Multi-región no es gratis ni en costo ni en complejidad operacional. El operational overhead es real: cada recurso que existe en una región ahora existe en dos o más, con todo lo que eso implica en mantenimiento, monitoreo y actualizaciones. Los costos de transferencia de datos entre regiones también se acumulan rápido si no se modelan desde el inicio.

Antes de empezar, vale la pena hacer un ejercicio de planeación con una matriz de prioridad, esfuerzo, complejidad y dependencias — algo similar al Método Eisenhower. No todo tiene que regionalizarse al mismo tiempo ni con la misma urgencia. Siempre hay componentes que son candidatos naturales para regionalizarse primero (típicamente los más críticos y con menor complejidad de replicación) y otros que pueden esperar.

Un Well Architected Review es un buen punto de partida para hacer ese inventario con una metodología estructurada.

La arquitectura evoluciona

El estado final de una arquitectura multi-región en AWS se ve algo así: el usuario llega a Route 53, que rutea al CloudFront más cercano, que a su vez dirige el tráfico a la región correspondiente — donde viven el API Gateway, las Lambdas y la base de datos Aurora replicada. Todo gestionado por certificados en ACM y con tráfico distribuido por políticas de latencia o failover en DNS.

Llegar ahí no pasa de un día para otro. Llega por iteraciones, con IaC como columna vertebral y con una estrategia de DNS que desde el primer día esté pensada para escalar.

Multi-región no es un problema de servicios, es un problema de diseño. Los servicios de AWS están listos. La pregunta es si tu arquitectura, tu código y tus procesos también lo están.

Multi-Stage Continuous Delivery

Franchesco Romero — Thu, 02 Apr 2026 21:59:47 +0000

Multi-Stage Continuous Delivery - Speaker Deck

speakerdeck.com

El problema con los pipelines tradicionales

El concepto de Multi-Stage CD es sencillo: llevas código a prod en varias iteraciones y a través de diferentes ambientes — dev, staging, prod — con fases bien definidas: build, prepare, deploy, test, notify, rollback. Suena limpio. Y en papel, lo es.

El problema es la realidad. Según el State of DevOps Report 2020, el 95% del tiempo se va en mantenimiento de pipelines, el 80% en tareas manuales, y el 90% en remediación también manual. Nadie escribe esas métricas en su README, pero todos las vivimos.

Los retos concretos son tres y son los de siempre: la disponibilidad de ambientes (el clásico "no le muevan a dev que estoy probando algo"), satisfacer dependencias externas correctamente — JS, Python, AWS, lo que sea — y los ambientes con candado cuando hay un bug en prod y todo se paraliza. A eso le sumas llegada lenta a producción, más de siete herramientas involucradas en el proceso, y pipelines distintos para web, API y mobile que cada quien personalizó a su manera. El resultado es un Frankenstein difícil de mantener para cualquier persona del equipo.

Lo que realmente se necesita no es magia: capacidad de poner ambientes en cuarentena, dependencias siempre disponibles y seguras, configuración que realmente funcione, y despliegues validados con tests, métricas de performance y SLOs/SLIs bien definidos.

Keptn: un control plane para gobernarlos a todos

La solución que propongo es Keptn — y el título de esta sección es intencional. Keptn es una plataforma open source de orquestamiento que automatiza la configuración y provee en un solo control plane todo lo que normalmente está disperso: monitoreo, despliegue, remediación y resiliencia.

Lo que lo hace diferente es su enfoque declarativo y orientado a GitOps. Defines tus ambientes y estrategias en un archivo shipyard.yaml y Keptn se encarga de la orquestación basada en eventos. No necesitas escribir la lógica de coordinación entre herramientas — eso ya está resuelto.

Desde el punto de vista de plataforma, Keptn entrega progressive delivery, automatización de SRE, auto-remediación y rollback, y una configuración codificable e independiente de herramientas. Pero la parte más importante: mantiene conectividad con las herramientas que ya tienes — JMeter, Argo, Jenkins, Helm, lo que ya está corriendo en tu stack.

Un beneficio que no es obvio a primera vista: los pipelines tradicionales dejan de ser necesarios. Keptn reemplaza esa necesidad con fases dedicadas y orquestamiento event-driven. Tienes estrategias out-of-the-box como Blue/Green y Canary, más observabilidad integrada en el proceso con auditabilidad y trazabilidad completas.

Cómo funciona por dentro

El modelo mental es el siguiente: Keptn expone servicios a los cuales las herramientas se suscriben por medio de integraciones. Los eventos de Keptn se traducen a llamadas API hacia y desde esas herramientas.

En la práctica: Keptn crea un evento y lo distribuye a cualquier servicio que esté escuchando — por ejemplo, sh.keptn.event.hello-world.triggered. El Job Executor Service (JES) detecta el evento, busca la configuración en el YAML correspondiente y ejecuta el contenedor. Una vez que termina, el JES envía de vuelta un par de eventos .started y .finished. Keptn los recibe, sabe que la tarea está completa y avanza en la secuencia. Simple, trazable, predecible.

El ecosistema de integraciones es amplio. Para despliegue: Argo, Jenkins, CircleCI. Para observabilidad: Prometheus, Grafana, Splunk. Para testing: JMeter, Selenium, Artillery. Para notificaciones: Slack, webhooks, Tekton. Para automatización: Ansible, webhooks, AWS Lambda. La idea es clara — Keptn maneja la orquestación, las tareas y la ejecución; nosotros decidimos las herramientas.

Por qué esto importa frente a pipelines tradicionales

La comparación es directa. Los pipelines tradicionales sufren de falta de separación de responsabilidades, código lleno de dependencias y personalizaciones ad hoc, y dificultad para incorporar herramientas específicas sin romper todo. Keptn resuelve esto con fases dedicadas y orquestamiento basado en eventos, interoperabilidad a través de abstracciones bien definidas, y flexibilidad real para cambiar herramientas sin reescribir la lógica de entrega.

Próximos pasos: quality gates y progressive delivery

Una vez que el flujo básico está corriendo, los casos de uso avanzados son los que realmente cambian el juego. Los Quality Gates basados en SLI/SLO permiten que un despliegue sólo avance si cumple criterios medibles — por ejemplo, que el porcentaje de éxito de probes sea mayor al 95%, o que la duración de respuesta sea menor a 200ms. El score total determina si el pipeline pasa o emite una advertencia.

El Progressive Delivery lleva esto un paso más lejos: defines un flujo que va de dev a hardening a production, con estrategias blue/green en los ambientes de mayor criticidad y remediación automatizada en prod. Keptn evalúa quality gates entre cada etapa y sólo promueve si los números lo justifican.

El punto de todo esto no es adoptar una herramienta más por el gusto de hacerlo. Es reconocer que los pipelines monolíticos tienen un techo bajo, y que un modelo orientado a eventos con separación clara de responsabilidades escala mucho mejor — tanto en complejidad técnica como en tamaño de equipo.

Si quieres profundizar, el punto de partida es keptn.sh y los recursos de la comunidad en keptn.sh/resources/slides.

Optimización de costos para transacciones de alto volumen

Franchesco Romero — Thu, 02 Apr 2026 21:51:48 +0000

Optimización de costos para transacciones de alto volumen - Speaker Deck

speakerdeck.com

Optimización de Costos para Transacciones de Alto Volumen en AWS

Cuando se habla de optimización de costos en AWS, la conversación suele ir a los mismos lugares de siempre: Reserved Instances, Savings Plans, apagar recursos que no usas. Todo eso está bien y deberías hacerlo, pero hay un nivel más profundo que la mayoría de los equipos no toca — las decisiones de arquitectura y tecnología que generan costos innecesarios a escala sin que nadie se dé cuenta. Este post va sobre eso.

La economía oculta de las API calls

En arquitecturas serverless, cada llamada API tiene un costo. Eso parece obvio, pero las implicaciones no siempre son visibles cuando estás diseñando el sistema.

El patrón más común que genera costo silencioso es el polling. Imagina una aplicación que consulta un endpoint REST cada 5 segundos para verificar si hay nuevas órdenes en DynamoDB. A volumen bajo nadie lo nota. A volumen alto, estás pagando por miles de requests a API Gateway y Lambda que en su mayoría regresan vacío. La corrección es dejar de preguntar y empezar a escuchar: DynamoDB Streams detecta los cambios en la tabla y los envía a EventBridge, que filtra y transforma el evento antes de disparar el downstream — SNS, Step Functions, WebSockets. Cero polling, costo proporcional al trabajo real.

Otro patrón costoso es usar Lambda para cada operación que pasa por API Gateway. Si tienes un frontend enviando datos JSON que necesitan ser validados y escritos en DynamoDB, el reflejo natural es meter una Lambda en el medio. El problema es que cada invocación tiene costo. API Gateway tiene Mapping Templates que pueden hacer validaciones y transformaciones de request sin necesidad de invocar ninguna función. Para operaciones simples y de alto volumen, eliminar esa Lambda puede significar cientos de miles de invocaciones menos por mes.

El tercer caso tiene que ver con los límites internos de AWS. Cuando una aplicación escribe a DynamoDB a alta velocidad y alcanza el límite de Write Capacity Units, AWS aplica backoff exponencial y genera reintentos automáticos — que también cuestan. Meter SQS como buffer entre la aplicación y DynamoDB nivela el throughput y elimina esos reintentos, convirtiendo un patrón de escritura caótico en uno predecible y controlable.

Data transfer: el costo que nadie presupuesta

La transferencia de datos en AWS tiene una particularidad: es casi invisible en el diseño inicial y muy visible en la factura a fin de mes.

El ejemplo más costoso y fácil de corregir es usar NAT Gateway para que instancias en subnets privadas accedan a S3. NAT Gateway cobra por procesamiento de datos — a $0.045 por GB, 5TB al mes son $225 adicionales que no agregan ningún valor técnico. La solución es un VPC Endpoint para S3: el tráfico fluye directamente dentro de la red de AWS sin pasar por NAT, sin costo por transferencia. Es una de las optimizaciones con mejor ratio esfuerzo/impacto que existen.

Para APIs con alto tráfico de lectura, CloudFront delante de API Gateway puede eliminar la gran mayoría de invocaciones a Lambda. Si configuras CloudFront para cachear respuestas comunes por 5 minutos, todo ese tráfico repetido deja de llegar al backend. Para catálogos de productos, configuraciones, datos de referencia — el impacto puede ser dramático.

El caso de GenAI agrega una dimensión nueva. Si tienes un chatbot en AWS que manda cada query a un modelo externo como OpenAI, estás pagando transferencia de datos de salida en cada request. Mover el modelo a Amazon Bedrock o SageMaker dentro de AWS no solo elimina esa transferencia — también te da más control sobre latencia, disponibilidad y costos por token.

La economía del almacenamiento

El formato de compresión que usas para tus datos puede parecer un detalle técnico menor. En cargas de análisis a escala, no lo es. GZIP es el default en muchos pipelines de Redshift, EMR y Glue, pero tiene latencia de descompresión alta y peor ratio de compresión comparado con alternativas más modernas. Zstandard en nivel 3 ofrece mayor eficiencia tanto de almacenamiento como de procesamiento, con reducciones de más de un 30% en tamaño. Para 50TB de logs de transacciones, ese 30% es dinero real.

El zero-copy data sharing es otro concepto que vale la pena entender. El patrón ineficiente es copiar datos entre cuentas de AWS para que cada equipo tenga su propia copia en S3. Cada copia es storage adicional, cada sincronización es transferencia. Con AWS Lake Formation y Glue Catalog Cross-Account, puedes dar acceso a las mismas tablas registradas a múltiples cuentas sin mover un solo byte. Los datos viven en un lugar, el acceso se gestiona con permisos.

Computación selectiva: elegir bien el tipo de recurso

Aquí hay una distinción que muchos equipos no hacen: no todos los workloads tienen el mismo cuello de botella. Algunos son CPU-intensivos, otros son memory-bound, otros son IO-bound. Elegir la familia de instancia equivocada significa pagar por recursos que no estás usando.

Un ejemplo concreto: una base de datos MySQL en RDS con instancias t3.medium que tiene la RAM llena y hace swapping a disco. El problema no es CPU — es memoria. La solución no es subir a una instancia con más CPU, es cambiar a una familia memory-optimized. Las instancias R6g con Graviton2 ofrecen 50% más memoria por dólar que T3. Para Elasticsearch con alto uso de IOPS donde EBS gp3 ya es el cuello de botella, instancias I4i con almacenamiento NVMe local reducen la latencia de consultas en un 60%.

En Lambda, la relación memoria-CPU tiene una implicación de costos contraintuitiva. Con 128MB de RAM, una función de procesamiento de imágenes puede tardar 6 segundos. Con 1024MB tiene acceso a una vCPU completa y la misma operación tarda 0.8 segundos — 7 veces más rápida. Lambda Power Tuning existe para encontrar el punto óptimo entre costo por ejecución y tiempo de ejecución, y el resultado frecuentemente sorprende: más memoria puede ser más barato.

En Kubernetes, el costo escala con el número de nodos, y el número de nodos escala con el número de pods. Si cada microservicio tiene su propio pod con límites de CPU y memoria dedicados, terminas con mucha capacidad reservada que en promedio está subutilizada. Consolidar servicios relacionados en pods multi-tenant reduce el número total de nodos necesarios y mejora la utilización del clúster.

Estrategias de bases de datos

Aurora tiene una característica que justifica su adopción para cargas intensivas en I/O: Aurora I/O-Optimized elimina el cobro por operaciones de lectura y escritura, cambiando el modelo de precio a uno más predecible basado en capacidad. Si tienes un workload con miles de IOPS, la diferencia puede ser sustancial. Combinado con auto-tiering para mover datos históricos a almacenamiento más barato y Aurora Backtrack para reducir snapshots innecesarios, el costo total de una instancia de 5TB puede bajar considerablemente.

Para logs de transacciones en PostgreSQL que crecen a millones de registros con el tiempo, la solución no es escalar la instancia — es particionar los datos por tiempo. En lugar de una tabla gigante donde las consultas escanean todo el historial, particiones mensuales o diarias limitan el scope de cada query al período relevante. Amazon Timestream también es una alternativa cuando el patrón de acceso es fundamentalmente time-series.

Con DynamoDB a escala, TTL es una herramienta de costo que se subestima. Los ítems expirados se eliminan automáticamente sin consumir Write Capacity Units, lo que mantiene la tabla limpia sin operaciones de borrado explícitas. DAX como capa de caché elimina lecturas repetidas a la tabla principal y DynamoDB Streams permite reaccionar a cambios sin polling — ambos ya cubiertos en la sección de API calls.

Los anti-patterns que hay que evitar

Tan importante como saber qué optimizar es saber qué no hacer. Over-engineering en arquitecturas event-centric es frecuente: agregar capas de EventBridge, SNS y SQS a flujos que podrían ser síncronos simples, creando complejidad operacional por ahorros marginales que nunca se materializan.

El mito de que serverless siempre es más económico que servidores es exactamente eso: un mito. Para cargas con throughput constante y predecible, un servicio administrado de contenedores o incluso instancias reservadas pueden salir más baratos que pagar por invocación a escala. El modelo correcto depende del patrón de tráfico.

Los logs sin filtrar son otro agujero silencioso. Loggear todo en CloudWatch Logs a nivel DEBUG en producción, sin retention policies, sin filtros, genera costos de ingesta y almacenamiento que crecen con el tráfico. Filtrar a nivel del source, definir retention apropiado y usar Log Insights solo cuando se necesita mantiene eso bajo control.

La conclusión más importante es también la más sencilla: la optimización no es un proyecto con fecha de inicio y fin, es una práctica continua. Las estrategias no convencionales que van más allá de Reserved Instances y right-sizing pueden aportar entre un 15-30% adicional de ahorro. Pero solo si el equipo tiene cultura de cost awareness integrada desde el diseño, no como una corrección posterior.

Optimizando Cargas de Trabajo Serverless Técnicas para mejorar Rendimiento y Eficiencia

Franchesco Romero — Thu, 02 Apr 2026 21:19:45 +0000

Optimizando Cargas de Trabajo en Lambda - Speaker Deck

speakerdeck.com

Este post va sobre las técnicas que realmente mueven la aguja cuando estás buscando rendimiento y eficiencia en Lambda.

Cómo está construido lo que estás ejecutando

Lambda tiene una arquitectura en capas que vale la pena entender antes de optimizar cualquier cosa: tu función vive dentro de un Language Runtime, que a su vez corre en un Execution Environment, administrado por el Lambda Service sobre un Compute Substrate. Cada capa tiene implicaciones en cómo se comporta tu función al arrancar y durante la ejecución.

Dos mecanismos que se aprovechan bien una vez que entiendes esto son las Layers y las Extensions. Las capas te permiten separar tu código de función de sus dependencias y recursos compartidos — librerías, SDKs, utilerías comunes — y reutilizarlos en múltiples funciones sin empaquetar lo mismo en cada deployment. Las extensiones, por su parte, se integran en el ciclo de vida de la invocación para conectar Lambda con herramientas de monitoreo, seguridad y observabilidad, corriendo en paralelo al runtime sin modificar el código de tu función.

El problema de los Cold Starts

Si hay un tema que aparece en todas las conversaciones sobre Lambda es este. Un cold start ocurre cuando AWS necesita provisionar un nuevo contexto de ejecución — descarga el código, levanta el entorno, inicializa el runtime, y luego ejecuta tu función. Esto pasa con cambios de código, durante scale-up, en rebalanceos de AZs, o después de fallos.

El impacto varía bastante por runtime. Python y JavaScript tienen cold starts en el rango de 200-500ms. Java y Docker pueden llegar fácilmente al segundo y medio. No es lo mismo si tienes una API interactiva donde el usuario espera la respuesta, que un pipeline batch asíncrono donde nadie nota 800ms extra.

La estrategia más simple para mitigarlo es el warmup con eventos de CloudWatch o EventBridge que disparan la función cada X minutos para mantenerla activa. Funciona, pero tiene sus trade-offs: es periódico, no puedes controlar qué instancias específicas se calientan, y a escala puede tener un costo no despreciable. Haz los números: una sola función ejecutándose cada 5 minutos cuesta alrededor de $0.18 al mes. Diez funciones: $14.58 más costos de CloudWatch. No es dramático, pero tampoco es gratis.

La alternativa más robusta es Provisioned Concurrency: le dices a Lambda cuántos entornos de ejecución quieres inicializados y listos en todo momento. Por cada unidad de simultaneidad aprovisionada se mantienen mínimo dos entornos en AZs separadas, lo que también da alta disponibilidad. El contra es que pagas por esa capacidad aunque no la uses, y hay restricciones importantes: no funciona con $LATEST ni con Lambda@Edge. Úsalo con inteligencia — tiene más sentido en runtimes de inicio lento como Java, y puedes combinarlo con Application Auto Scaling para ajustar la capacidad según patrones de tráfico.

Para Java específicamente, SnapStart es un game changer: toma una snapshot del estado inicializado de la función y la restaura en invocaciones posteriores, logrando hasta 10x mejora en tiempo de arranque sin cambios en el código. Disponible desde la consola, SAM y CDK.

Vale mencionar también LLRT (Low Latency Runtime) — un runtime JavaScript liviano escrito en Rust que AWS Labs lanzó como experimental. Ofrece inicio hasta 10x más rápido y costo hasta 2x menor comparado con el runtime de Node.js estándar. Si estás en JavaScript y los cold starts te están afectando, vale la pena explorarlo.

Right-sizing y optimización de costos

Más memoria no siempre significa más costo — en Lambda, memoria y CPU están acoplados, así que a veces asignar más RAM resulta en ejecuciones más rápidas que al final cuestan lo mismo o menos. El problema es que nadie sabe exactamente cuánta memoria necesita una función sin medirlo.

Para esto existe AWS Lambda Power Tuning, una State Machine de Step Functions que ejecuta tu función con diferentes configuraciones de memoria, mide duración y costo, y te da una visualización clara del trade-off. La diferencia entre la configuración óptima para costo (1536MB en el ejemplo de la presentación) vs. la óptima para velocidad (3008MB) puede ser significativa, y depende completamente de tu workload específico.

Otros recursos útiles para right-sizing son AWS Compute Optimizer, Lambda Insights, y DevOps Guru, que pueden darte recomendaciones basadas en patrones de uso histórico.

Si tu workload tolera migrar a arm64 (Graviton2), el ahorro en precio/performance es aproximadamente un 34% frente a x86. La migración no es siempre trivial — lenguajes compilados y algunos containers requieren adaptaciones — pero el beneficio es real y verificable con Lambda Power Tuning comparando ambas arquitecturas. Los Compute Savings Plans también aplican a Lambda y pueden dar hasta un 17% adicional de ahorro sobre demanda.

Optimizaciones que están en tu control

Hay cosas que AWS optimiza por ti (descarga del código, setup del entorno) y cosas que dependen de ti (init code y handler code). La mayor palanca que tienes está en mantener tus funciones ligeras: dependencias mínimas, frameworks más pequeños, sin código muerto, y empaquetado en un único archivo minificado. El tamaño del ZIP afecta directamente cuánto tarda Lambda en descargar y cargar tu función.

Lazy-loading es otra práctica que marca diferencia: en lugar de importar todo al inicio del módulo, carga las dependencias solo cuando realmente se necesitan. El código de la presentación lo ilustra bien tanto en JavaScript como en Python — inicializas el cliente de DynamoDB o S3 dentro del handler, condicionado a si ya está inicializado, y lo reutilizas en invocaciones posteriores dentro del mismo contexto de ejecución.

Para bases de datos relacionales, si estás llamando RDS desde Lambda, RDS Proxy resuelve el problema de agotamiento de conexiones que ocurre cuando Lambda escala agresivamente. Agrupación de conexiones, mayor disponibilidad y caché de queries — sin cambios en el código de la función.

Si tu función sirve respuestas que no cambian con cada invocación, configurar caché a nivel de API Gateway o CloudFront puede eliminar completamente la invocación de Lambda para esas peticiones. Para algunos patrones esto es la optimización más impactante de todas.

Métricas que realmente importan

Medir promedios de latencia es engañoso. Lo que importa es el percentil p95 o p99 — el rendimiento que experimentan el 5% o el 1% más lento de tus usuarios. Un promedio de 200ms con un p99 de 4 segundos es una función con problemas serios que el promedio oculta.

AWS X-Ray es la herramienta para esto: tracing end-to-end de requests, service map de tu aplicación, y visibilidad sobre exactamente dónde se producen los cuellos de botella. Un Tracing: Active en tu template de SAM o CDK y ya tienes trazas automáticas de Lambda y los servicios downstream.

El punto que más se subestima

Lambda no debería ser el default para absolutamente todo. Hay operaciones donde otros servicios hacen el trabajo mejor y más barato sin invocar ninguna función. Orquestación compleja de workflows: Step Functions. Filtrado de mensajes antes de procesarlos: SNS con filter policies. Scheduling de tareas: EventBridge Scheduler. Integrar Lambda innecesariamente en esos flujos agrega latencia y costo sin valor real.

Optimizar Lambda no es una sola cosa — es la suma de decisiones en configuración, código, arquitectura y monitoreo. El punto de partida es medir con X-Ray, ajustar con Lambda Power Tuning, y construir con las restricciones del caso de uso en mente, no con el toolset que conoces mejor.

Mejorando tu Seguridad en AWS con ML y AI

Franchesco Romero — Thu, 02 Apr 2026 21:10:57 +0000

Mejorando tu Seguridad en AWS con ML y AI - Speaker Deck

speakerdeck.com

Mejorando tu Seguridad en AWS con ML y AI

Las aplicaciones modernas son complejas, distribuidas, y cada nuevo servicio que agregas es también una nueva superficie de ataque potencial. A eso súmale el volumen brutal de logs, métricas y trazas que genera una plataforma en producción, y tienes la receta perfecta para que identificar la causa raíz de un incidente se convierta en una tarea que consume horas — o días — de personas con conocimiento muy especializado.

Las amenazas tampoco se quedan quietas. Suplantación de identidad, ransomware, fraudes, amenazas internas, accesos no autorizados... la lista es larga y la frecuencia con la que ocurren no para de crecer. El problema de la seguridad tradicional es que trabaja con reglas fijas y estáticas, y los atacantes hace mucho que aprendieron a moverse entre los huecos que esas reglas dejan.

¿Qué necesitamos realmente?

Más allá de detectar incidentes, necesitamos hacerlo rápido. Reducir el tiempo de detección, de triaging, de debugging. Necesitamos protección continua que se adapte a nuestra operación, que nos ayude a cumplir con marcos normativos, y que no nos despierte a las 3am por un falso positivo. En resumen: necesitamos que el sistema aprenda.

Y ahí es donde entran ML y AI.

Cómo funciona

El concepto es sencillo: un algoritmo aprende a reconocer patrones en datos históricos, y una vez entrenado, usa ese conocimiento para hacer predicciones sobre datos nuevos y disparar acciones en consecuencia. Nada de magia, pura estadística aplicada a escala. Lo interesante es cómo AWS ha integrado esto directamente en sus servicios de seguridad, sin que tengas que construir ni operar los modelos tú mismo.

Las aplicaciones concretas van desde detección de anomalías en tráfico de red — identificar un DDoS antes de que te rompa el día — hasta modelado de comportamiento para detectar actividad maliciosa o fraudulenta que ningún operador humano hubiera notado a tiempo.

Los servicios que importan

Amazon GuardDuty es el punto de entrada natural. Es un servicio administrado que usa ML para analizar de forma continua eventos de CloudTrail, VPC Flow Logs y DNS Logs. Lo que hace bien es identificar patrones: acceso inicial sospechoso, escalación de privilegios, reconocimiento, acciones defensivas del atacante para cubrir sus huellas. No tienes que configurar reglas; el modelo se encarga.

Amazon Detective entra cuando ya ocurrió algo y necesitas entender qué pasó. Usa aprendizaje automático para analizar los mismos logs y te da contexto: qué cuentas estuvieron involucradas, desde qué IPs, qué recursos tocaron, y desde dónde geográficamente. La diferencia entre tardar 2 horas o 2 días en contener un incidente muchas veces está en tener ese contexto disponible de inmediato.

CloudWatch tiene algo que mucha gente no usa: detección automática de anomalías basada en ML. Analiza el histórico de tus métricas, aprende el comportamiento esperado, y te permite definir ventanas de detección y umbrales de tolerancia adaptados a tu operación — por ejemplo, excluir el ruido durante una ventana de deployments.

Para cumplimiento normativo, Amazon Macie usa ML para descubrir y clasificar datos sensibles en S3: PII, datos financieros, credenciales expuestas.

AWS DevOps Guru apunta más hacia el análisis predictivo: monitoreo continuo con algoritmos de ML sobre tus métricas de aplicación, detectando comportamientos anómalos antes de que se conviertan en incidentes, y creando automáticamente OpsItems en SSM OpsCenter para que el equipo los atienda.

Finalmente, IAM Access Analyzer usa Automated Reasoning — no ML clásico, sino análisis formal — para revisar tus políticas de IAM e identificar configuraciones que podrían permitir acceso no autorizado. Es el tipo de análisis que un humano haría manualmente en una auditoría, automatizado y corriendo de forma continua.

Lo que hay que tener claro

Ninguno de estos servicios es plug-and-play en el sentido de que funciona perfecto desde el día uno. Hay un período de aprendizaje — entre 15 minutos y 48 horas dependiendo del servicio — y cada ambiente es único, así que la configuración importa. El punto más importante, y el que más confunde a los equipos que recién empiezan: anómalo no es lo mismo que vulnerable, roto o malicioso. Un comportamiento fuera de lo normal es una señal para investigar, no necesariamente una alarma de incendio.

La combinación de GuardDuty, Detective, Macie, CloudWatch Anomaly Detection y DevOps Guru crea una capa de seguridad inteligente que detecta lo que las reglas estáticas no ven, responde más rápido de lo que cualquier equipo humano podría, y se adapta al comportamiento real de tu plataforma. ML y AI ya son parte central de la oferta de seguridad de AWS — la pregunta no es si usarlos, sino cuáles activar primero.

Dominando el Caos en Cargas de Trabajo Sin Servidores

Franchesco Romero — Thu, 02 Apr 2026 20:44:50 +0000

Dominando el Caos en Cargas de Trabajo Sin Servidores - Speaker Deck

La ingeniería del caos implica provocar intencionalmente interrupciones en las cargas de trabajo, generalmente en servidores tradicionales. En esta char…

speakerdeck.com

Dominando el Caos en Cargas de Trabajo Sin Servidores

La ingeniería del caos es la práctica de introducir fallos intencional y proactivamente en un sistema para identificar y solucionar debilidades. Esta definición suena contraintuitiva — ¿por qué romper algo que funciona? — pero la premisa es simple: si no pruebas cómo falla tu sistema en condiciones controladas, lo descubrirás en el peor momento posible.

Los beneficios son concretos: mejor resiliencia, mayor disponibilidad, experiencia de usuario más confiable, y equipos que confían en sus sistemas porque los han probado de verdad.

Pre-requisitos antes de introducir el caos

No se puede empezar a romper cosas sin preparación. Antes de ejecutar cualquier experimento de caos en un entorno serverless, hay cinco condiciones que deben estar cubiertas.

Primero, necesitas tener pruebas existentes — un suite de tests que defina qué es comportamiento correcto, para poder detectar desviaciones cuando introduces fallos.
Segundo, debes conocer a fondo la arquitectura: qué servicios están involucrados, cómo se comunican, qué dependencias existen.
Tercero, hay que determinar alcances y riesgos antes de ejecutar, no durante — saber exactamente qué se puede afectar y qué queda fuera de scope.
Cuarto, es preferible contar con entornos dedicados para los experimentos más agresivos; no todo debe probarse en producción desde el primer día.
Quinto, necesitas monitoreo y observabilidad en su lugar antes de comenzar, porque sin métricas no puedes saber qué está pasando durante el experimento.

El ciclo del caos

La ingeniería del caos no es caos sin estructura — es un ciclo bien definido. Empieza con una hipótesis: una pregunta específica sobre el comportamiento del sistema bajo estrés. A partir de ella se diseña un experimento, se crean los fallos, se analizan los resultados, se corrigen los fallos encontrados, se valida la hipótesis, y los aprendizajes alimentan mejora continua que genera nuevas hipótesis. El ciclo se repite.

El diseño de cada experimento sigue cuatro pasos: definir el estado estable (los KPIs que representan operación normal), formular la hipótesis (qué se espera que pase bajo estrés), especificar la definición y ejecución (tipos de fallo, sistemas a probar, condiciones), y establecer el monitoreo y análisis (cómo se verificarán los KPIs y las desviaciones).

Un ejemplo concreto: dado un API Gateway multi-región con funciones Lambda detrás de un enrutamiento basado en latencia, la hipótesis sería que inyectar latencia en una región no debería afectar el rendimiento de las demás, y que Route 53 debería detectar el aumento de latencia y redirigir el tráfico a una región más saludable. La ejecución del experimento tendría tres componentes: acción (inyectar latencia en Lambda), objetivo (funciones Lambda en una región específica), y condición de monitoreo (métricas de latencia en CloudWatch).

Técnicas de inyección de fallos

Hay tres categorías principales de fallos que se pueden inyectar en entornos serverless.

Resiliencia de red cubre latencia en respuestas y pérdida de paquetes — los fallos más comunes en sistemas distribuidos y los más fáciles de introducir de forma controlada.

Interrupciones simula servicios no disponibles y respuestas inesperadas — el escenario donde una dependencia simplemente deja de responder o responde con errores.

Límites prueba qué pasa cuando se alcanzan los topes de uso de APIs, memoria, o tiempo de ejecución — particularmente relevante en Lambda donde estos límites son hardcoded.

Más allá de la capa de red, los fallos también pueden inyectarse a nivel de código, de ambiente, o de configuración — tres vectores distintos que cubren la mayoría de los escenarios de fallo reales.

Herramientas disponibles en AWS

Para entornos serverless en AWS, hay cuatro opciones principales que vale comparar:

AWS Fault Injection Service (FIS) es el servicio nativo de AWS, 100% manejado e integrado con el ecosistema. Es programable desde consola, CLI y CDK, permite experimentos controlados tanto en secuencia como en paralelo, y opera a todos los niveles — red, infra, aplicación. Tiene excelente documentación pero tiene costo por uso.

Chaos Toolkit es una herramienta open source para caos en entornos generales. Documentación buena, facilidad media, gratuita.

Chaos_lambda está enfocada en fallos a nivel de runtime de Lambda. Documentación limitada, gratuita.

Failure Lambda opera a nivel de código de Lambda. También gratuita pero con documentación limitada.

Para la mayoría de los casos en AWS, FIS es la opción más práctica por su integración nativa y el nivel de control que ofrece.

AWS Fault Injection Service en detalle

Un experimento en FIS se construye con cuatro componentes: una plantilla de experimento que define todo lo que va a ocurrir, acciones que especifican qué fallos se van a introducir, objetivos que determinan sobre qué recursos se aplican (por ejemplo, instancias EC2 con tags específicos), y condiciones de paro vinculadas a alarmas de CloudWatch que detienen el experimento si las cosas se salen de control.

Para entornos serverless específicamente, FIS soporta los siguientes fallos: DynamoDB no responde, una región completa no funciona, Lambda tarda mucho en responder, Lambda responde con error, y throttling de API. Estos cubren los escenarios de fallo más comunes en arquitecturas event-driven y de microservicios sin servidor.

El monitoreo durante los experimentos se hace con CloudWatch para métricas, X-Ray para rastreo distribuido, y dashboards personalizados que permiten ver el comportamiento en tiempo real mientras el experimento está activo.

La arquitectura de implementación de FIS para Lambda sigue un flujo claro: FIS lee una plantilla de experimento, ejecuta una automatización que interactúa con Parameter Store para configurar el comportamiento de caos, y la Lambda bajo prueba reporta métricas a CloudWatch. En el caso del patrón Chaos Injection Lambda Layers, FIS orquesta a través de una plantilla y una automatización que actualiza Parameter Store, y la Lambda tiene un Chaos Lambda Layer adicional que lee esa configuración e inyecta el comportamiento anómalo antes de ejecutar el código de negocio. Esto permite activar y desactivar el caos sin modificar el código de la función.

La extensión chaos-lambda-extension es otro patrón que opera dentro del ambiente de ejecución de Lambda: se registra como una extension que se ejecuta junto al runtime, intercepta las invocaciones a través de la Extension API y la Runtime API, e inyecta los fallos configurados antes de que el código de la función se ejecute. Es más invasiva que las Lambda Layers pero también más precisa.

Técnicas de resiliencia para responder al caos

Identificar dónde falla el sistema es la mitad del trabajo. La otra mitad es construir resiliencia que haga que los fallos sean manejables. Hay tres principios fundamentales para aplicaciones serverless con tolerancia a fallos:

Redundancia significa tener múltiples instancias de los componentes críticos — en el contexto serverless, esto se traduce en deployments multi-región, DLQs para mensajes fallidos, y funciones de respaldo.

Degradación elegante implica mantener funcionalidad parcial cuando un componente falla. En lugar de retornar un error 500, la aplicación retorna una respuesta reducida pero funcional — datos en caché, respuestas por defecto, o funcionalidad limitada con un mensaje claro al usuario.

Recuperación automatizada significa que los procesos de recuperación de fallos no dependen de intervención manual. Los runbooks deben ejecutarse solos.

A nivel de código, las tres técnicas más importantes son lógica de reintento con backoff exponencial, circuit breakers, y throttling.

La lógica de reintento con backoff exponencial es el patrón básico de resiliencia para fallos transitorios. En Python con boto3, se traduce a reintentar la operación hasta N veces, con un time.sleep(2 ** attempt) entre intentos — los tiempos de espera crecen exponencialmente para no sobrecargar un servicio que ya está bajo presión.

Los circuit breakers son más sofisticados: un objeto que rastrea el número de fallos consecutivos y, cuando supera un umbral, abre el circuito durante un período de recuperación. Durante ese período, las llamadas fallan inmediatamente sin intentar la operación, dando tiempo al servicio dependiente de recuperarse. Una vez pasado el timeout de recuperación, el circuito se cierra y las operaciones se reanudan.

Los límites de throttling en API Gateway, configurados a través de UsagePlans con BurstLimit y RateLimit, protegen los backends de ser sobrecargados bajo picos de tráfico inesperados.

Mejores prácticas

Independientemente de las herramientas que uses, hay cinco principios que aplican a cualquier práctica de ingeniería del caos:

Comenzar pequeño. El primer experimento no debe ser "apagamos una región". Empieza con latencia en una función, en un ambiente de staging, con radio de blast controlado.

Automatizar. Los experimentos ejecutados manualmente son inconsistentes y difíciles de repetir. Automatizar la ejecución, el monitoreo y la condición de paro desde el principio.

Monitorear de cerca. No ejecutes un experimento y te vayas a hacer otra cosa. El valor está en observar el comportamiento en tiempo real.

Comunicar. El equipo necesita saber cuándo se está ejecutando un experimento, qué se está probando, y cuál es el plan de rollback. Los experimentos no anunciados generan pánico innecesario.

Documentar. Cada experimento, sus resultados, y los cambios que generó deben quedar registrados. La ingeniería del caos sin documentación es simplemente romper cosas.

Resumen

La ingeniería del caos en entornos serverless no es una práctica de nicho — es una necesidad para cualquier sistema que aspire a alta disponibilidad. AWS FIS hace que sea significativamente más accesible.

Integrando IA generativa con Bases de Datos relacionales en AWS

Franchesco Romero — Thu, 02 Apr 2026 20:15:07 +0000

Integrando IA generativa con Bases de Datos relacionales en AWS - Speaker Deck

En esta charla mostraremos cómo AWS Bedrock puede conectarse a una base de datos tradicional, comprender su estructura, y generar consultas a partir de …

speakerdeck.com

Integrando IA Generativa con Bases de Datos Relacionales en AWS

Foundation Models y el ecosistema de Bedrock

Antes de entrar en la implementación, vale la pena aclarar los conceptos base. La IA Generativa, en términos prácticos, es un tipo de IA capaz de crear nuevo contenido: textos, conversaciones, resúmenes, imágenes.

Los Foundation Models son los modelos de aprendizaje automático que hacen esto posible, entrenados sobre cantidades masivas de datos no etiquetados y luego adaptados para tareas específicas como generación de texto, extracción de información, Q&A o chatbots.

AWS Bedrock es el servicio que te da acceso a varios de estos modelos — desde Claude de Anthropic hasta Titan de Amazon, Llama 2 de Meta, Mistral, Cohere y Stable Diffusion — a través de una API unificada, sin tener que administrar infraestructura de ML por tu cuenta.

Arquitectura

La arquitectura que propuse es deliberadamente simple: un usuario interactúa con una aplicación, esta invoca una Lambda Function, la Lambda se conecta a Amazon Aurora, y Aurora llama a Bedrock directamente usando Aurora ML. Este componente es la pieza central del patrón — Aurora ML es una característica de Amazon Aurora (disponible desde la versión 3.06 en adelante) que permite invocar algoritmos de machine learning directamente desde SQL. Esto significa que puedes hacer un SELECT que internamente llama a un Foundation Model en Bedrock y regresa el resultado como si fuera cualquier otro valor de la base de datos. La simpleza de esto es lo que hace la integración tan poderosa: los datos nunca salen de Aurora, no hay ETL, no hay pipelines intermedios.

Pre-requisitos

La configuración requiere cuatro pasos previos:

Crear un IAM Role con los permisos necesarios para que Aurora pueda llamar a Bedrock, y asignar ese rol al cluster.
Habilitar los modelos base en la consola de Bedrock para la región donde está tu cluster — esto es un paso explícito que AWS requiere antes de poder usarlos.
Crear las funciones SQL que mapean a cada modelo de Bedrock.

Este último paso es lo más interesante: con apenas un CREATE FUNCTION que usa el alias AWS_BEDROCK_INVOKE_MODEL y especifica el MODEL ID, ya tienes disponible en tu base de datos una función que puedes llamar desde cualquier query o stored procedure. En la demo creé dos funciones, una para Amazon Titan y otra para Claude 3 Haiku.

CREATE FUNCTION invoke_titan (request_body TEXT)
RETURNS TEXT
ALIAS AWS_BEDROCK_INVOKE_MODEL
MODEL ID 'amazon.titan-text-express-v1'
CONTENT_TYPE 'application/json'
ACCEPT 'application/json';

CREATE FUNCTION claude3_haiku (request_body TEXT)
RETURNS TEXT
ALIAS AWS_BEDROCK_INVOKE_MODEL
MODEL ID 'anthropic.claude-3-haiku-20240307-v1:0'
CONTENT_TYPE 'application/json'
ACCEPT 'application/json';

Casos de uso

Para ilustrar los patrones usé el dataset público de películas de IMDb, que incluye títulos, calificaciones, géneros e información de personas.

Insights de cultura pop

El primer caso fue generar análisis culturales sobre películas de los 90s. Un stored procedure itera sobre las películas más populares de la década, construye un prompt con el título, año y géneros de cada una, lo pasa a Claude 3 Haiku vía la función SQL, y guarda el resultado en una tabla de title_insights. El modelo recibe el contexto de que la película fue lanzada en los 90s y genera análisis sobre qué reflejaba sobre el momento histórico, qué tendencias capturaba y por qué resonó con su audiencia. Todo esto ejecutado desde un simple CALL generate_90s_insights().

Consultas en lenguaje natural

El segundo caso fue más interesante: un stored procedure natural_language_query recibe una pregunta en texto libre — por ejemplo, "Encuentra las 10 películas mejor calificadas de la década de 1990" — y hace dos cosas. Primero, le pasa esa pregunta a Bedrock junto con el schema de la base de datos como contexto, pidiendo que genere únicamente el SQL necesario para responderla. Segundo, ejecuta ese SQL generado dinámicamente con PREPARE y EXECUTE.

El truco está en el prompt engineering: hay que ser muy explícito en las instrucciones — solo SQL ejecutable, sin explicaciones, sin markdown, sin backticks — y luego limpiar la respuesta con REGEXP_REPLACE antes de ejecutarla. El resultado es que un usuario sin conocimiento de SQL puede hacer preguntas en lenguaje natural y obtener resultados reales de la base de datos.

Resumen de películas

El tercer caso fue enriquecimiento en batch: un procedimiento que toma películas sin resumen en la base de datos, construye un prompt con título, año y géneros, y le pide a Claude que genere una descripción breve. El resultado se guarda directamente con un UPDATE. Un CALL generate_movie_summaries() es todo lo que necesitas para enriquecer un catálogo entero.

Casos avanzados

Más allá de estos tres patrones básicos, la integración abre posibilidades más sofisticadas: análisis de query plans con sugerencias de índices, detección de anomalías en datos con propuestas de corrección automática, o análisis de evolución de schemas. En todos los casos el patrón es el mismo — datos de Aurora como contexto, Foundation Model como motor de razonamiento, resultado guardado de vuelta en la base de datos.

Mejores prácticas

Hay cuatro áreas que vale subrayar:

Safe defaults. Configurar defaults seguros tanto a nivel de base de datos como del cliente, para evitar que errores del modelo afecten datos críticos.

Chain of Transformations. Pensar en los flujos de enriquecimiento como cadenas de transformaciones explícitas: get_data() → enrich_with_ai() → validate_data() → store_in_db(). No mezclar estas responsabilidades en un solo procedimiento.

Prompt Engineering con templates. La calidad del output depende directamente de la calidad del prompt. Vale la pena invertir tiempo en construir plantillas bien estructuradas y reutilizables.

Caching, rate limiting y manejo de errores. Implementar caching inteligente para consultas similares, rate limiting para evitar resource exhaustion cuando el volumen escala, y manejo de errores robusto para cuando el modelo devuelve algo inesperado.

Observabilidad

Las métricas que más importan en este tipo de integración son:

Latencia de generación de prompts
Tasa de éxito y fallo de llamadas al LLM
Calidad de respuestas (requiere algún tipo de evaluación downstream)
Consumo de tokens y costos asociados
Cache hit/miss ratio

Consideraciones

El control de acceso a datos sensibles es una preocupación válida. Bedrock Guardrails y el abuse detection nativo son los mecanismos disponibles para esto. También hay que tener en cuenta las limitaciones inherentes de precisión de los modelos, que hacen necesario validar outputs antes de usarlos en decisiones críticas.

Para quienes prefieran alternativas open source, el patrón equivalente sería PostgreSQL o MariaDB conectado a LangChain, con LLaMA 2 o Mistral como modelo, y un Vector Store para búsqueda semántica. Es una arquitectura perfectamente válida, con más flexibilidad pero también más infraestructura que administrar.

Resumen

Este patrón es valioso por tres razones concretas: facilita el acceso a datos complejos sin mover nada fuera de la base de datos, puede incorporarse a infraestructuras Aurora existentes sin rediseño mayor, y aprovecha Foundation Models de clase mundial con la misma interfaz SQL que tu equipo ya conoce.

El código de la demo está disponible en GitHub bajo Amazon Bedrock and Aurora MySQL Integration.

AWS mas allá de la nube con IAM Anywhere y Amazon Verified Permissions

Franchesco Romero — Thu, 02 Apr 2026 18:46:26 +0000

Cuando hablamos de seguridad en AWS, la conversación casi siempre empieza y termina en IAM.

Pero hay un escenario que muchas organizaciones enfrentan y que no siempre tiene una respuesta obvia: ¿qué pasa cuando el workload que necesita acceder a recursos en AWS no vive dentro de AWS?

Hay compañías con regulaciones estrictas de seguridad y cumplimiento que mantienen parte de su infraestructura detrás de data centers propios o firewalls corporativos. Hay equipos en medio de migraciones o modernizaciones que todavía tienen servidores tradicionales que necesitan hablar con servicios en la nube. En todos estos casos, la solución más obvia — usar access keys — trae consigo una lista de problemas conocidos: pueden olvidarse, necesitan rotarse periódicamente, hay que controlar cómo se exponen, y las sesiones expiran de formas que a veces nadie monitorea. Sin mencionar que la trazabilidad de quién usó qué credencial y cuándo se vuelve una pesadilla de auditoría.

La respuesta que propusimos es IAM Roles Anywhere, un servicio que permite emitir credenciales temporales de AWS para cargas de trabajo que viven fuera de la nube, ya sean servidores bare metal, contenedores on-prem o cualquier aplicación corriendo en un data center corporativo.

El mecanismo de verificación se basa en certificados X.509 y PKI, lo que significa que en lugar de manejar access keys estáticas, estás manejando una infraestructura de confianza basada en certificados — algo que los equipos de seguridad entienden y controlan mucho mejor.

Primero, una Certificate Authority emite certificados para cada carga de trabajo, confirmando que son entidades reconocidas dentro de tu infraestructura.
Luego se configura un Trust Anchor en AWS que referencia esa CA — usando AWS Private CA es la ruta más integrada, aunque también puedes usar Let's Encrypt u otra CA pública si entiendes las implicaciones de a quién le estás otorgando confianza.
Finalmente, cuando una carga de trabajo necesita credenciales, presenta su certificado firmado por la CA, firma la solicitud con su llave privada, y AWS devuelve credenciales temporales para el IAM Role asociado.
Todo esto orquestado por el aws_signing_helper, el credential helper oficial que hace que el proceso sea transparente para tus aplicaciones.

En Terraform, la implementación se divide en tres recursos principales: la aws_acmpca_certificate_authority para levantar la CA privada, el aws_rolesanywhere_trust_anchor que la referencia y sirve como punto de confianza, y el aws_rolesanywhere_profile que define qué IAM Role puede ser asumido por qué carga de trabajo. El IAM Role en sí se configura de la misma forma que cualquier otro, con la diferencia de que el principal en el assume role policy es rolesanywhere.amazonaws.com y las acciones incluyen sts:SetSourceIdentity para mejor trazabilidad.

Una de las cosas que más me gusta de esta arquitectura es que el monitoreo queda completamente integrado con los servicios nativos de AWS. CloudWatch Metrics te da visibilidad sobre expiración de certificados e intentos de login fallidos.

CloudTrail registra todos los eventos relevantes de API. Y con EventBridge puedes construir automatizaciones sobre cualquiera de esos eventos — por ejemplo, una alerta cuando un certificado está próximo a expirar o cuando hay un patrón anómalo de intentos fallidos.

En cuanto a mejores prácticas, la recomendación central es tratar esto exactamente como tratas cualquier estrategia de IAM: un rol por carga de trabajo, mínimo privilegio, y roles exclusivamente asumibles por rolesanywhere para no abrir superficies de ataque innecesarias.

IAM Roles Anywhere como servicio no tiene costo — lo que sí tiene costo es AWS Private CA, que vale la pena evaluar contra alternativas como usar una CA pública, siempre considerando el modelo de confianza que eso implica.

También es importante configurar soporte para CRL (Certificate Revocation Lists) desde el principio, porque si un certificado se pierde o se compromete, necesitas poder revocarlo sin tener que reconstruir toda la cadena de confianza.

DEV Community: Franchesco Romero

Coordinar deploys de frontend y backend sin orquestado, usando Github Actions

El Setup

elchesco / github-actions-combined-deploy-with-no-orchestrator

Coordinating frontend and backend deploys without an orchestrator:

Code companion — frontend/backend deploy coordination post

Suggested reading order

Notes

TL;DR

El problema

Las opciones

Opción 1: workflows paralelos independientes (el baseline de no hacer nada)

Opción 2: colapsar en un solo workflow con orden explícito

Opción 3: el frontend gatea contra el SHA del backend (el gate simple)

Opción 4: pin del frontend a un artifact buildeado del backend

Cómo elegir

Etapa 0: el punto de partida

Etapa 1: detectar el push acoplado

Etapa 2: hacer poll al run del backend por SHA

Etapa 3: manejar el "todavía no se registra"

Etapa 4: superficies de error con sentido

El resultado

Lo que NO ayudó

Qué sí ayudaría a futuro

Lecciones

Bajándole todos los minutos posibles al CI del backend con mas de 1000 tests

elchesco / improve-ci-times

improve-ci-times

Code companion — backend CI optimisation post

Suggested reading order

Notes

Intento no. 1: instalar dependencias más rápido con uv

Intento no. 2: BuildKit cache mounts en el Dockerfile

Intento no. 3: la trampa de pytest-xdist

Trampa 1: DROP SCHEMA entre workers

Trampa 2: max_locks_per_transaction

Trampa 3: la divergencia del DATABASE_URL

Intento no. 4: template database de PostgreSQL

Trampa 4: filelock se cuelga

Intento no. 5: la medición que rompió el supuesto

Round 6: soltar xdist, irse a 4 shards

El resultado

Otras cosas que probe y que definitivamente no ayudaron

Qué sí ayudaría a futuro

Lecciones

elchesco / improve-ci-times

improve-ci-times

Code companion — backend CI optimisation post

Suggested reading order

Notes

Bajándole todos los minutos posibles al CI del backend con mas de 1000 tests

Intento no. 1: instalar dependencias más rápido con uv

Intento no. 2: BuildKit cache mounts en el Dockerfile

Intento no. 3: la trampa de pytest-xdist

Trampa 1: DROP SCHEMA entre workers

Trampa 2: max_locks_per_transaction

Trampa 3: la divergencia del DATABASE_URL

Intento no. 4: template database de PostgreSQL

Trampa 4: filelock se cuelga

Intento no. 5: la medición que rompió el supuesto

Round 6: soltar xdist, irse a 4 shards

El resultado

Otras cosas que probe y que definitivamente no ayudaron

Qué sí ayudaría a futuro

Lecciones

Pros y Cons de las arquitecturas multi-región

Pros y Cons de las arquitecturas multi-región - Speaker Deck

Los retos reales de ir multi-región

Tolerancia a fallos: el modelo mental que todo lo rige

Las capas de una arquitectura multi-región

Monitoreo: no es opcional, es parte de la arquitectura

Despliegue: IaC o no escala

Lo que realmente hay que considerar antes de empezar

La arquitectura evoluciona

Multi-Stage Continuous Delivery

Multi-Stage Continuous Delivery - Speaker Deck

El problema con los pipelines tradicionales

Keptn: un control plane para gobernarlos a todos

Cómo funciona por dentro

Por qué esto importa frente a pipelines tradicionales

Intento no. 1: instalar dependencias más rápido con `uv`

Intento no. 3: la trampa de `pytest-xdist`

Trampa 1: `DROP SCHEMA` entre workers

Trampa 2: `max_locks_per_transaction`

Trampa 3: la divergencia del `DATABASE_URL`

Trampa 4: `filelock` se cuelga

Round 6: soltar `xdist`, irse a 4 shards

Intento no. 3: la trampa de `pytest-xdist`

Trampa 1: `DROP SCHEMA` entre workers

Trampa 2: `max_locks_per_transaction`

Trampa 3: la divergencia del `DATABASE_URL`

Trampa 4: `filelock` se cuelga

Round 6: soltar `xdist`, irse a 4 shards