gov-pay
Үндсэн ойлголтууд

Rate limit

API key тус бүрд тогтоосон хүсэлтийн хязгаар ба 429 хариунд хэрхэн зохицох

GovPay channel-api нь API key тус бүрд хүсэлтийн тоог Redis дээр тоолж хязгаарладаг. Хязгаар нь гулсах цонхоор (sliding window) ажиллах ба гурван түвшинд зэрэг хэрэгжинэ.

Хязгаарууд

ЦонхХязгаар
1 секунд5 хүсэлт
1 минут60 хүсэлт
1 цаг1000 хүсэлт

Гурван хязгаарын аль нэг нь хэтэрвэл хүсэлт 429 Too Many Requests буцаана. Тооцоо API key бүрд тусдаа явагдах тул өөр key-ууд бие биедээ нөлөөлөхгүй.

Хязгаар нь key тус бүрд хамаарна — нэг key-ийн ачаалал нөгөө key-ийн квотыг зарцуулахгүй. Sandbox болон production орчны хязгаар ижил.

429 нь зөвхөн rate limit-ийн алдаа. Бусад кодыг Алдааны кодууд хуудаснаас үзнэ үү.

429 хариу

{
  "statusCode": 429,
  "message": "Too Many Requests"
}

429-д хэрхэн зохицох

1. Backoff + дахин оролдох

429 ирвэл шууд дахин бүү дуудаарай. Хүлээх хугацааг экспоненциалаар нэмэгдүүлж (жишээ нь 1с → 2с → 4с → 8с), дээр нь бага зэрэг санамсаргүй jitter нэмж дахин оролдоно. Энэ нь олон хүсэлт нэгэн зэрэг дахин дуудагдаж дахин 429 авахаас сэргийлнэ.

async function callWithRetry(fn, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const res = await fn();
    if (res.status !== 429) return res;

    // Экспоненциал backoff + jitter
    const base = 2 ** attempt * 1000; // 1с, 2с, 4с, 8с...
    const jitter = Math.random() * 500;
    await new Promise((r) => setTimeout(r, base + jitter));
  }
  throw new Error("Rate limit: дахин оролдлого дууссан");
}

2. Хүсэлтээ тараах (throttle)

Та секундэд 5-аас илүү хүсэлт дамжуулахгүй байхаар клиент талдаа queue эсвэл throttle тавьвал 429-д огт хүрэхгүй. Багц боловсруулалт (жишээ нь олон нэхэмжлэл шалгах) хийж байгаа бол хүсэлтүүдийн хооронд жижиг хүлээлт тавьж жигд тараана.

3. Кэш ашиглах

Аль болох дотоод систем рүүгээ дуудалт цөөлнө:

  • Нэг нэхэмжлэлийг ойр давтан шалгах бол төрийн системээс шинээр татах GET /invoices/{id}/refresh-ийн оронд DB cache-аас уншдаг GET /invoices/{id}-г сонгоно.
  • Аль болох өөрийн талд кэшлэх боломжтой хариунуудыг (нэхэмжлэлийн мэдээлэл, статус) дахин дахин бүү татаарай.

4. Polling-ийн оронд webhook

Төлбөрийн статусыг секунд тутам GET /payments/{id}-аар асуухын оронд Webhook бүртгэвэл payment.submitted / payment.confirmed event-ийг GovPay өөрөө таныруу түлхэнэ. Энэ нь polling-ийн ачааллыг бараг бүрэн арилгаж rate limit-д хүрэх эрсдэлийг бууруулна.

Идемпотент бус хүсэлтийг (жишээ нь POST /payments) сохроор дахин бүү оролдоорой. 429 нь хүсэлт серверт хүрээгүй гэсэн утгатай тул дахин оролдоход аюулгүй; гэхдээ найдвартай байхын тулд POST /payments дээр X-Idempotency-Key ашиглаж давхардлаас сэргийлээрэй. Дэлгэрэнгүйг Төлбөр хуудаснаас.

Хязгаараа нэмэгдүүлэх

Хэрэв таны бодит ачаалал эдгээр хязгаараас тогтмол давдаг бол GovPay-тэй холбогдоно уу. Бид таны хэрэглээний загвар (хүсэлтийн төрөл, оргил ачаалал)-д тулгуурлан key-ийн хязгаарыг тохируулна. Хүсэлт гаргахдаа дараахыг бэлдээрэй:

  • Аль endpoint-ууд хамгийн их ачаалалтай вэ
  • Хүлээгдэж буй секунд/минут/цагийн оргил хүсэлтийн тоо
  • Багц боловсруулалт эсвэл бодит цагийн урсгал эсэх