AutoJob

Contexto

En el trabajo remoto el tiempo importa: una buena vacante encontrada tarde compite con todos los que la encontraron primero. Revisar bolsas de trabajo a mano es lento, y la mayoría de las vacantes no encaja.

El problema

Necesitaba tres cosas que las alertas de empleo genéricas no hacen juntas:

1. Encontrar vacantes temprano, lo más cerca posible de cuando se publican.
2. Filtrar por encaje, no por palabra clave — con reglas que pueda leer, probar y explicar.
3. Avisar sin ruido: lo que vale la pena atender ya, por separado; lo demás, una vez al día.

Arquitectura

Generando diagrama…

• n8n — transporte, no lógica. Trae las fuentes, normaliza cada item y llama funciones SQL para registrar la corrida y sus payloads crudos. A la hora de avisar, entrega mensajes cuyo texto ya redactó SQL.
• Funciones SQL de Postgres. Toda regla vive aquí: ingesta, deduplicación, filtro, el filtro geográfico, qué merece alerta y qué va al resumen. Las reglas en SQL se versionan y prueban como migraciones, y sobreviven si algún día el núcleo sale de n8n.
• canonical_hash. La deduplicación usa un hash que es una columna generada en Postgres, con restricción única, así que se calcula igual para cada fila sin importar qué workflow la insertó.
• Telegram, con rate limit. Un mensaje a la vez con una pausa entre ellos; ante un 429 espera el retry_after que pide la API y reintenta una vez. Los topes por corrida — 3 alertas individuales, 15 líneas por resumen — evitan que una ráfaga de vacantes se vuelva una ráfaga de mensajes.

Decisiones clave y trade-offs

La parte difícil

Los NULL. Dos campos los volvieron caros.

El hash canónico. La forma obvia de construirlo, concat_ws, se salta los NULL en silencio — así que los campos cambian de posición y vacantes distintas pueden producir la misma cadena:

-- concat_ws se salta los NULL, así que los valores cambian de posición:
select concat_ws('|', 'a', null, 'b');  -- a|b
select concat_ws('|', 'a', 'b', null);  -- a|b   ← mismo resultado, distinta entrada

-- Un coalesce explícito por campo deja cada valor en su lugar:
select coalesce('a', '') || '|' || coalesce(null, '') || '|' || coalesce('b', '');  -- a||b
select coalesce('a', '') || '|' || coalesce('b', '') || '|' || coalesce(null, '');  -- a|b|

En una llave de deduplicación, esa colisión significa que una vacante real se descarta como duplicada. La columna generada usa un coalesce explícito por campo en vez de concat_ws, y después saca el hash SHA-256 del resultado.

posted_at. La detección temprana depende de saber cuándo se publicó algo. Un valor faltante no se puede reemplazar sin más por la hora de ingesta: una vacante vieja parecería nueva y dispararía una alerta. Por eso los dos usos de la fecha van separados:

-- Para el filtro de antigüedad, cae a la hora de ingesta solo si la fuente no es confiable:
effective_posted_at := case
  when posted_at_confidence = 'unknown' then ingested_at
  else coalesce(posted_at, ingested_at)
end;

-- Una alerta individual exige una fecha exacta y reciente. Un posted_at NULL vuelve
-- NULL la comparación, así que nunca califica: cae al resumen diario.
when posted_at_confidence = 'exact' and posted_at > now() - max_age then 'high'

Resultados

Medido el 2026-09-24, sobre todas las vacantes ingeridas desde el 21 de septiembre.

Vacantes ingeridas en 3 días

1,197

Himalayas 552 · Jobicy 539 · RemoteOK 106 — unas 400 al día.

Pasaron el filtro

27 (2.3%)

Todo lo demás se descartó automáticamente.

Pases que no podía tomar desde México

18 de 27

Vacantes restringidas por región. La medición llevó a una regla geográfica basada en la ubicación estructurada de cada fuente.

Resumen diario, antes → después de la regla geo

~9 → ~3

Vacantes por día, sobre los mismos datos medidos.

Stack