Files
2nd/10_Wiki/Topic_Programming/Coding/Backend_Job_Queue_Patterns.md
T
Antigravity Agent 9148c358d0 docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
2026-07-05 00:33:48 +09:00

4.0 KiB

id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases
id title category status source_trust_level verification_status created_at updated_at tags tech_stack applied_in aliases
backend-job-queue-patterns Job Queue 패턴 — 비동기 작업 영속화 Coding draft B conceptual 2026-05-09 2026-05-09
backend
queue
worker
async
vibe-coding
language applicable_to
TypeScript / BullMQ / SQS / RabbitMQ
Backend
worker
dead letter queue
delayed job
scheduled job

Job Queue 패턴

"이 작업이 결국 실행되어야 한다 — 실패해도 재시도, 사용자 응답은 즉시" 가 답. producer / queue / worker / DLQ 4단 구조 + 멱등성 + 모니터링.

📖 핵심 개념

  • Producer: HTTP handler 가 요청 받자마자 enqueue, 사용자에게 202.
  • Queue (broker): Redis (BullMQ), AWS SQS, RabbitMQ, Kafka 등.
  • Worker: 별도 프로세스. 동시성 / 백프레셔 제어.
  • DLQ (Dead Letter Queue): 최대 재시도 후에도 실패한 메시지 격리.

💻 코드 패턴

BullMQ (Redis 기반, Node)

import { Queue, Worker, QueueEvents } from 'bullmq';
const conn = { connection: { host: 'redis', port: 6379 } };

// Producer
const emailQ = new Queue('email', conn);

app.post('/api/welcome-email', async (req, res) => {
  await emailQ.add('welcome', { userId: req.body.userId }, {
    attempts: 5,
    backoff: { type: 'exponential', delay: 1000 },
    removeOnComplete: 1000,    // 마지막 1000개만 보관
    removeOnFail: false,        // 실패는 보관
  });
  res.status(202).end();
});

// Worker (별도 프로세스)
const worker = new Worker('email', async (job) => {
  if (job.name === 'welcome') {
    await sendWelcomeEmail(job.data.userId);
  }
}, {
  ...conn,
  concurrency: 10,
  limiter: { max: 100, duration: 1000 }, // 초당 100건 제한
});

worker.on('failed', (job, err) => {
  log.error('job failed', { id: job?.id, attempts: job?.attemptsMade, err });
});

Idempotent worker

async function sendWelcomeEmail(userId: string) {
  const already = await db.emails.exists({ userId, kind: 'welcome' });
  if (already) return; // 멱등
  await mailer.send(...);
  await db.emails.insert({ userId, kind: 'welcome', sentAt: new Date() });
}

Delayed / scheduled

// 1시간 뒤
await emailQ.add('reminder', data, { delay: 60 * 60 * 1000 });

// Cron — 매일 오전 9시
await emailQ.upsertJobScheduler('daily-digest', { pattern: '0 9 * * *' }, { name: 'digest', data: {} });

DLQ

worker.on('failed', async (job, err) => {
  if (job?.attemptsMade === job?.opts.attempts) {
    await dlq.add('email-dead', { original: job.data, error: err.message, jobId: job.id });
  }
});

🤔 의사결정 기준

작업 도구
짧은 (<100ms) + 사용자 응답에 결과 필요 동기 처리
외부 API 호출 (이메일, 결제, 푸시)
파일 처리 / PDF 생성 / 이미지 변환
이벤트 fan-out (한 이벤트 → 여러 핸들러) Pub/Sub (Kafka, NATS)
정확한 시각 실행 스케줄러 (BullMQ scheduler / Temporal)
복잡 워크플로우 (sagas) Temporal / Inngest

안티패턴

  • HTTP 요청 안에서 큰 작업 동기 처리: 사용자 30초 대기 + timeout.
  • worker 가 멱등 X: at-least-once delivery → 중복 효과.
  • DLQ 없음: 영구 실패 잡 무한 retry 또는 silently drop.
  • monitoring 없음: queue 길이 / 실패율 모름. 백로그 폭발.
  • worker concurrency 제한 없음: DB / 외부 API 부하 폭증.
  • 메시지 안에 큰 payload: 큐 메모리 폭발. ID 만 + DB/blob 보조.
  • graceful shutdown 미흡: deploy 시 진행 중 잡 손실. SIGTERM 받으면 현재 잡 끝나고 종료.
  • 순서 보장 가정 (대부분 큐는 FIFO 아님): 명시적 순서 필요시 partition key.

🤖 LLM 활용 힌트

  • "큐 설정 + worker 멱등 + DLQ + monitoring 4종 세트" 강제.
  • BullMQ / SQS / Kafka 중 어떤지 명시.

🔗 관련 문서