Helpdesk scaling and launch checklist

• Pagination: Queues and ticket histories use keyset pagination on (created_at, id) with indexed filters; counts in the inbox come from cached per-queue counters, not COUNT(*) scans.
• Caching: SLA policies, routing rules and public knowledge articles are cached per org and invalidated on change; ticket content is never cached across users.
• Idempotency: Inbound email is deduped by message id; API ticket creation honours Idempotency-Key; SLA breach actions are recorded once per (ticket, level).
• Rate limits: Portal, public form and API submissions are rate limited per IP, requester and key; outbound auto-replies are capped per recipient per day.
• Search: Ticket and article search use Postgres full-text with org filters; revisit a dedicated engine only after p95 exceeds 800 ms at 5M tickets.
• Data growth: ticket_events and audit_log are partitioned by month and archived to read-only partitions after 24 months.

• Metric tickets created total: by channel and priority.
• Metric sla breach total: by metric, team and tier.
• Log ticket event log: request id, actor, ticket id, action; message bodies excluded.
• Trace inbound email trace: webhook, dedupe, parse, ticket create, notification.
• Slo email ingest latency: 95% of inbound emails become tickets within 60 seconds.
• Alert email loop detected: one requester receiving > 20 auto-messages per hour.
• Alert sla sweep stalled: sweep not completing within two minutes.

• sla_sweep: runs cron every minute. Guard: indexed scan of running timers only; each breach recorded once and escalation fires once per level.
• process_inbound_email: runs queue (jobs) on webhook. Guard: dedupe by message id, loop and auto-reply detection, attachment scan, bounded size.
• send_notifications: runs queue (jobs) on ticket events. Guard: one email per (event, recipient), daily cap per requester to stop loops.
• rollup_ticket_metrics: runs cron hourly. Guard: idempotent upsert per (org, day, team).
• warranty_and_lifecycle_alerts: runs cron daily. Guard: one alert per (asset, threshold).
• auto_close_resolved: runs cron daily. Guard: closes resolved tickets after the configured days; reopened by requester reply.

• Read replicas: Analytics and exports run on a read replica when primary CPU > 60% sustained; agent inbox uses the primary.

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.

When should I worry about scale for a helpdesk?

Not before a measured trigger fires. For example, for "Live chat and SMS channels": customers request non-email channels.

What performance targets should a helpdesk aim for?

Agent inbox load (50 rows): p95 < 300 ms. Ticket page with 200 events: p95 < 450 ms. Inbound email to visible ticket: p95 < 30 s end to end.

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.

• How to build a helpdesk
• Helpdesk architecture
• Example prompt for a helpdesk
• Helpdesk security checklist
• Often combined: SaaS dashboard
• Often combined: CRM
• All app types