Approval workflow app scaling
Approval workflow app scaling and launch checklist
An approval workflow app stays fast by paginating every list, indexing the main questions, and deferring heavy work until a measured trigger fires. At launch, apply 5 rules, watch 5 signals and hold the performance targets below.
Last checked
Rules to apply at launch
- Pagination: Request and audit lists use keyset pagination on an indexed cursor, page size 25 capped at 100.
- Caching: Dashboard totals read per-tenant daily rollups, cached for 30 s.
- Queues: Escalation and notification delivery are Postgres jobs claimed with SKIP LOCKED by capped workers.
- Rate limits: Per-tenant and per-IP token buckets on invites, API keys and login; exceeded limits return 429.
- Data growth: audit_log and notifications grow monotonically: partition by month and purge read notifications after 90 days.
Performance targets
| What to measure | Target |
|---|---|
| Decision API | p99 < 150 ms, one compare-and-set plus audit insert |
| Request list | p95 < 250 ms, keyset paginated |
| Escalation lag | p99 overdue step escalated within 10 minutes |
What to watch
- Metric approval cycle time s: submit to final decision, by tenant and amount band.
- Metric escalation rate: share of steps escalated; spikes mean an unstaffed approver role.
- Log decision log: request id, step, decision, actor type; no request body.
- Slo approval availability: 99.9% of decision calls return a definitive result.
- Alert self approval attempt: any attempt to decide your own request is alerted.
Recurring work
- escalate_overdue: runs cron 5m. Guard: SKIP LOCKED batch, status predicate makes it idempotent, never escalates past the last step.
- send_notifications: runs cron 1m. Guard: outbox claim with attempt cap and per-tenant daily cap.
Add when the numbers say so
- Read replicas: Serve dashboards and exports from a read replica once primary CPU or dashboard p95 crosses the trigger.
Deferred until it is needed
| Deferred | Adopt it when |
|---|---|
| ERP and chat integrations | paying tenants request a specific connector. |
| Read replicas for dashboards | primary CPU > 60% sustained or dashboard p95 > 500 ms. |
On Forge64
Forge64 matches your description to one of 25 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.
Every metered resource on Forge64 has a hard cap, so a traffic spike stops at your limit instead of becoming a surprise bill. This is a reference design for the category, not a promise that every item is generated today. Built-ins such as background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it is something you add yourself for now.
FAQ
- When should I worry about scale for an approval workflow app?
- Not before a measured trigger fires. For example, for "ERP and chat integrations": paying tenants request a specific connector.
- What performance targets should an approval workflow app aim for?
- Decision API: p99 < 150 ms, one compare-and-set plus audit insert. Request list: p95 < 250 ms, keyset paginated. Escalation lag: p99 overdue step escalated within 10 minutes.
- Does Forge64 cap my usage costs?
- Yes. Every metered resource has a hard cap, and paid plans add an overage spend cap that you set.
Build your app with Forge64
One prompt to a running app with auth, database, hosting and payments. Start free, no credit card required.
Start building for free