Something about me is that I tend to be very straightforward. If your outfit looks terrible, I’ll probably tell you it looks terrible. Not because I’m trying to be rude, but because I believe honest feedback helps people improve. I also expect the same treatment in return. If I’m missing something or doing something wrong, I would rather hear the truth than have someone sugarcoat it to spare my feelings.
The same mindset applies when dealing with technical problems. Once a problem has already happened, spending too much time discussing how we got there doesn’t change the outcome. At that point, we’ve moved past prevention and into resolution. My preference is simple: solve the problem first, then talk about mitigation.
That same logic applies when building apps on Forge. If you spend too much time complaining about the limitations which are already there, you can't scale your apps.
Forge Is a Constrained Environment (By Design)
Forge often feels like a locked container. That’s not a flaw, it’s intentional.
The platform enforces strict rules around:
- Function execution time
- Invocation limits
- API request limits
- Storage limits
- Queue payload sizes
If you attempt to push beyond those boundaries, the platform simply restricts you. The operations you expected to run either slow down, fail, or get throttled.
So the real question becomes:
How do you build around Forge’s limitations?
One of the most discussed topics in the developer community is rate limiting.
And today, that’s exactly what we’re going to talk about.
Rate Limits: The Gatekeeper of System Scaling
Rate limiting is one of the most important mechanisms in any distributed system. It’s the control mechanism that prevents abuse, protects infrastructure, and ensures fair usage across tenants.
Forge is no different. If your app triggers too many:
- function invocations
- Atlassian REST API requests
- external requests
you will eventually encounter platform limits. This isn’t unique to Forge. It exists in AWS, GCP, and most large cloud systems.
The difference is that Forge is multi-tenant and heavily controlled, so those limits can surface quickly if your architecture isn’t designed properly.
Can You Avoid Forge Rate Limits?
Short answer: No.
Rate limits are part of the platform’s protection model.
Forge runs thousands of apps across many customers on shared infrastructure. Without rate limiting, a single misbehaving app could degrade the platform for everyone.
So avoiding rate limits entirely is not realistic.
The real goal is designing your app so that rate limits rarely become a problem.
The Real Risk Developers Should Think About
The bigger concern isn’t simply hitting rate limits during normal use.
The concern is uncontrolled request amplification.
For example:
- A poorly designed UI repeatedly triggering backend functions
- Bulk operations that fire too many API calls
- Users unintentionally triggering expensive operations
- Automated scripts interacting with your app
In extreme cases, this could resemble a DDoS pattern against your own app. So the responsibility ultimately falls on the app architecture itself.
Practical Patterns to Reduce Rate Limit Pressure
There is no single silver bullet, but several patterns help significantly.
Debouncing
Prevent repeated actions from triggering backend logic unnecessarily.
For example, if a user clicks a button multiple times within a short period, your app should ignore duplicate requests.
This avoids unnecessary function invocations.
Caching
Avoid requesting the same data repeatedly.
Cache results when possible, especially when interacting with Jira or Confluence APIs.
Examples include:
- Issue metadata
- configuration values
- frequently requested project data
Reducing repeated API calls dramatically lowers the chance of hitting limits.
Internal Rate Limiting
You can implement your own rate control within the app itself.
For example:
- queue operations instead of executing immediately
- throttle requests from specific workflows
- limit bulk operations per user action
This prevents your app from overwhelming the platform.
The Truth: No Two Apps Are the Same
The patterns above help reduce pressure on the system, but they won’t solve every situation. Different apps have very different workloads.
An app that analyzes Jira data across thousands of issues will behave very differently from an app that adds a UI panel. That’s why architecture matters.
In many cases, the long-term improvement that vendors hope for is more granular rate-limit isolation per installation or tenant, which would further reduce cross-impact between heavy and light usage scenarios.
The real challenge is learning how to build within those boundaries without constantly fighting them.
When you do that well, Forge becomes surprisingly powerful. When you ignore those constraints, scaling problems appear quickly.
In my next article, I’ll continue with Part 3 of scaling patterns, where we’ll look at more architectural strategies for building production-grade Forge apps.