시스템 설계 기초 — 캐싱·큐·샤딩·CAP

// ━━━ 1) 캐시 — cache-aside 패턴 (가장 흔함) ━━━
async function getUser(id: string) {
  const cached = await redis.get(`user:${id}`);
  if (cached) return JSON.parse(cached);         // 히트

  const user = await db.users.find(id);          // 미스
  await redis.set(`user:${id}`, JSON.stringify(user), "EX", 300);  // 5분
  return user;
}
// 무효화: 업데이트 시 `redis.del(\`user:\${id}\`)`

// ━━━ 2) 큐 — 이메일·이미지 처리 분리 ━━━
// 웹 핸들러에서는 job만 던지고 즉시 응답
await queue.add("sendWelcomeEmail", { userId: 42 });
return res.json({ ok: true });   // 사용자는 10ms 안에 응답 받음
// 별도 워커 프로세스가 큐를 읽어 실제 이메일 발송

// ━━━ 3) 샤딩 (개념) ━━━
// 유저 ID로 DB 선택
const dbIndex = hash(userId) % 8;      // 8개 샤드
const db = shards[dbIndex];
// 샤드를 넘어가는 JOIN은 어려워짐 → 신중한 분할 키 선택 필요

// Rate Limit — Redis INCR + EXPIRE (Fixed Window)
async function rateLimit(key: string, limit: number, windowSec: number) {
  const count = await redis.incr(key);
  if (count === 1) await redis.expire(key, windowSec);
  if (count > limit) throw new Error("Too Many Requests");
}

// 사용
app.use(async (req, res, next) => {
  try {
    await rateLimit(`rl:${req.ip}`, 100, 60);   // IP당 분당 100회
    next();
  } catch {
    res.status(429).json({ error: "rate limited" });
  }
});

// 정교한 슬라이딩 윈도우는 @upstash/ratelimit 등 라이브러리 사용