Helpdesk architecture
Helpdesk architecture: the decisions that matter
The architecture of a helpdesk comes down to 3 choices: email and web form as the launch channels, stored SLA timers recomputed on state change and asset register linked to the ticket system. Each is explained below with the alternatives that were rejected and what you accept by choosing it.
Last checked
Email and web form as the launch channels
Situation: Email is the universal support channel and needs no realtime infrastructure.
Choice: Ingest via provider webhooks into one ticket path; later channels reuse the same ingestion contract.
- Rejected: Chat first: needs realtime tier and staffing.
- Rejected: Email via mailbox polling: slower and fragile.
- Consequence: Threading relies on reply tokens.
- Consequence: Loop detection is mandatory.
Stored SLA timers recomputed on state change
Situation: Computing SLAs at query time is slow and inconsistent across business calendars.
Choice: A timer row per metric with due_at recomputed on pause, resume and priority change; sweep indexes running timers.
- Rejected: Compute on read: expensive reports.
- Rejected: Pure cron recalculation: drift.
- Consequence: State transitions must update timers in the same transaction.
- Consequence: Calendar changes trigger recompute jobs.
Asset register linked to the ticket system
Situation: IT teams need to see an asset's history when a ticket arrives.
Choice: Assets and assignments live in the same tenant schema and link to tickets and changes.
- Rejected: Separate asset tool: no linkage.
- Rejected: Full CMDB: scope too large for phase 1.
- Consequence: No auto-discovery in phase 1.
- Consequence: Imports must be good.
How the data is indexed
Indexes are chosen from the questions the app asks most often. Each line below names a table and the question its main index answers.
- requester_orgs: unique (org_id, name) — customer organisation name.
- tickets: unique (org_id, number) — human ticket number.
- ticket_events: (ticket_id, created_at) — conversation order.
- sla_policies: unique (org_id, name) — policy name.
- ticket_sla_timers: unique (ticket_id, metric) — one timer per metric.
- routing_rules: unique (org_id, position) — evaluation order.
- articles: unique (org_id, slug) — article url.
- assets: unique (org_id, tag) — asset tag.
What Forge64 provides underneath
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.
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
- What is the most important architecture decision for a helpdesk?
- Email and web form as the launch channels. Ingest via provider webhooks into one ticket path; later channels reuse the same ingestion contract.
- Do I have to make these decisions myself?
- No. Forge AI plans them from your description and writes the decisions into the project as architecture records you can read and change.
- What do the alternatives cost me?
- For example, for "Stored SLA timers recomputed on state change": Compute on read: expensive reports. Pure cron recalculation: drift.
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