Who this is for: Support leaders who want to know how Freshdesk stays fast and dependable as ticket volume and expectations grow.

At a glance

• What changed: SLAs, automations and agent assignment now run on an event-driven platform that reacts the moment a ticket changes.
• What customers get:
  1) Faster SLAs: SLAs as short as 30 seconds, with reminders and escalations triggered as soon as they apply.
  2) Smoother conversations: heavy background work no longer holds up messages between customers and agents.
  3) Steadier service: ticket changes are processed in order, recover automatically from temporary problems and stay steady during traffic spikes. 

What changed and why it matters

When an SLA clock runs late, reminders and escalations run late, and customers feel it. With every ticket change processed the moment it happens, teams get more accurate SLA clocks, reminders and escalations that fire on time, and agent assignment that reflects current workload. During a product launch, an outage or a seasonal peak, one account's surge is designed not to slow anyone else's service. The result is fewer missed SLAs caused by system delay, and less time spent second-guessing the platform.

Why we rebuilt it

Customers used to send an email and wait a few hours for an answer. Today they chat and message, and they expect replies in minutes, sometimes seconds. Every time a customer writes in, an SLA clock starts and the right agent needs to pick up the ticket. SLAs (service-level agreements) set how fast a team must respond to and resolve tickets, so they had to keep up. That is why we moved Freshdesk to an event-driven architecture: a design where the system reacts the moment something happens to a ticket, instead of waiting to be asked

The system now reacts the moment something happens to a ticket. It also keeps conversations unblocked: real-time messages between customers and agents are no longer held up by heavy work.

Resource-heavy jobs, such as calculating SLAs, running automations and assigning agents, now run in the background. They are processed in order and stay steady during traffic spikes, even when a noisy neighbor (an account whose heavy usage could otherwise slow others down) is on the platform.

What changes for customers

• Responsive conversations. Messages between customers and agents flow freely while heavy work runs in the background.
• Real-time SLA tracking. SLAs are tracked as things happen, so support teams see current SLA information, and reminders and escalations are triggered within moments.
• Consistent tickets. Changes are applied in the order they happened, so a ticket always shows its latest state.
• Steady during spikes. A surge from one account is designed not to slow other accounts down.
• Dependable recovery. Temporary problems are retried and recovered automatically.

How it works

The big picture

Every change to a ticket, such as a new ticket, a customer reply or an agent update, is sent as a small message through a messaging queue, a dependable conveyor belt between parts of Freshdesk. A coordinating service, which we call the orchestration engine, reads each message, decides what should happen next and calls the right specialized service. One service works out the SLA, another runs automations, and another assigns the best agent based on skills, workload and availability. Because each job lives in its own service, a service can be scaled or updated without disturbing the others, and trouble in one does not stop the rest.

Speed that holds up

In a single region, the system handles 200,000 ticket events per minute, where an event is any new ticket, reply or update. It is designed to scale by adding capacity, so each event is still processed quickly as volume grows.

Speed comes from keeping the part that reads the queue lightweight. It hands each message to a pool of workers and picks up more as soon as workers free up, so one slow task doesn't hold up the rest. If something restarts, the system resumes from a safe point, and it is designed never to skip a ticket event.

Tickets stay in order

Imagine a customer sends a message and, a moment later, updates it. Handled in the wrong order, the ticket could show outdated information. To prevent this, every change carries its ticket ID. The queue keeps all messages for one ticket in order, and a single worker handles that ticket's messages one after another, while different tickets are processed at the same time. Support teams get accuracy without giving up speed.

Ready for the unexpected

Things occasionally go wrong in any large system, so failure handling is built in.

• Automatic retries. Failed steps are retried, waiting a little longer each time. Each step can also be configured to stop, skip the failure or retry.
• Protection for struggling services. A circuit breaker pauses calls to a service that keeps failing, which gives it room to recover. What counts as a failure is configurable.
• Recovery for failed events. Messages that keep failing are held in a safe place and can be replayed after an incident, so ticket events are not lost.
• Protection from duplicates. Every message carries a unique ID, so a message that arrives again from a retry or a replay is recognized and ignored. This is called an idempotency check.

Busy neighbors do not slow others down

One customer's busy day should not become another customer's slow day. Accounts are assigned to separate groups, each with its own dedicated capacity, so a spike from one account, such as a very large import, stays contained. A busy account can be moved to another group through a setting, without a new release. Live traffic and bulk traffic also run separately, so a real-time ticket is not held up behind a large batch of background work.

Built to keep improving

The rules that drive these workflows are controlled through settings, not hard-coded, so behavior can be adapted quickly without risky large changes. It also means the same foundation now supports more than one service, so improvements made for one can benefit the others.

Our commitment

Reliability is something support teams should never have to think about. Our goal is that tickets are handled quickly, in the right order and without getting lost, whether a team receives a handful or a very large number. We will keep investing in the foundations that keep support fast, accurate and dependable as businesses grow.

What is the biggest SLA or reliability challenge your team faces today? Share it below; our product and engineering teams will be reading.