How to bypass the rate limit on the backend calls?

Once a month my app has a ton of usage and I always run into the Too many requests 429 error.

I am trying to optimize the queues and jobs to manage that, but as the platform is getting more and more users, I am not able to optimize it and running that in enough time.

I have seen I could use the dev api key, to bypass that limit.

Is that a good practice? Or what other options do I have?

Thanks

/**

• Pace an Appwrite SDK call through the global token bucket. Retries on 429
• with exponential backoff + jitter, respecting Retry-After / `X-RateLimit-
• Reset` when present. Any non-429 error is rethrown immediately.
• Usage:
• const doc = await withAppwriteCall(() =>
• TypeScript

  tablesDB.getRow({ databaseId, tableId, rowId })
  

• )
• Wrap at the REPO boundary, not at every call site — see the repo files for
• the canonical pattern. */ export async function withAppwriteCall<T>( fn: () => Promise<T>, opts: WithAppwriteCallOptions = {} ): Promise<T> { const maxRetries = opts.maxRetries ?? MAX_RETRIES const label = opts.label ?? 'appwrite' let attempt = 0

while (true) { const { waitedMs } = await acquireToken() stats.calls += 1 stats.totalWaitMs += waitedMs if (waitedMs > 0) stats.throttleWaits += 1

try {
  return await fn()
} catch (err) {
  if (!isRateLimitError(err)) throw err

  // 429 — apply retry logic.
  stats.rateLimitHits += 1
  if (attempt >= maxRetries) {
    throw new AppwriteThrottleExhausted(
      `[${label}] giving up after ${attempt + 1} attempts on 429`,
      attempt + 1
    )
  }
  stats.retries += 1
  const explicit = readRetryAfter(err)
  const sleepMs = explicit ?? backoffMs(attempt)
  console.warn(
    `[throttle] ${label} 429 attempt=${attempt + 1}/${maxRetries + 1} sleep=${sleepMs}ms (${explicit ? 'retry-after' : 'exponential'})`
  )
  await sleep(sleepMs)
  attempt += 1
  // Loop continues; we'll acquire a fresh token and retry.
}

} } also tryied using this

<@462046107556511744> Please need help

<@743532656767270934> any idea abt this?

Bro steven is not in core team anymore

Hey 👋

Rate limits should apply to specific IPs or users. I dont think spike of users active should cause rate limits.

Curious, do you use SSR capabilities without API key or session secret? Doing that might introduce global rate limit that you might be hitting.

As for dev keys, I would not recommend to use them on production, bad actor could use such dev key to harm your project.

Checking it rn

I have checked the codebase and not sure if i am using SSR capabilities

I mean we are using API KEY for sure on the server side.

And we call that using the cron, with a valid key.

.setKey(env.APPWRITE_API_KEY), and every Appwrite SDK call goes through that wrapped handle. Per-user JWT calls in verifyJwt.ts:15 use .setJWT(jwt), which is also a valid auth path (per-user bucket).

This being said, it should be impossible for me to be getting 429 errors in the cron runs from the server. I am using concurrent jobs, might that have anything to do?

<@287294735054274560> need help to solve this please

<@743532656767270934> any idea on this?

Please, I really need to solve this

<@1231860789355347971>

Use the Server SDK

It has no rate limits I believe

Is there any possibility that this could be happening because some of the calls are using JWT auth instead of only API-key-based server calls?

not from the server

i mean the front defenitely uses authenticted calls

But then the back is checking the jwt for calls comming from the front and then does whatever with the api key

And of course the cron function is also using API KEY

<@613275686060294145> Morning ☀️

Interesting indeed, can you share exact error message you are getting, and a piece of code that causes it? Alternatively, could you make a tiny demo app with just this concept?

I ask because once I can reproduce it, should be easily solvable

Yes, I am on it

Once I hit the rate limit this was the errors I was getting

I guess the piece of code can not be shared because it is an entire queue/jobs structure working on 4000 pieces of data that needed to be treated, that treatment is absolute core for our platform