Recruitment platforms and the scaling wall

A hiring platform comfortable at two hundred applications a day is often in trouble at five thousand, and the trouble is rarely where the team expects it. Web traffic is not usually the problem. Four things in a recruitment product get more expensive per unit as volume rises, and one of them runs at four in the morning where nobody is looking.

Matching goes quadratic before anyone notices

Candidate-to-role matching starts life as a query. A few filters, a text search across a few thousand profiles, a relevance score computed on the fly. It is fast and it is correct. It is also scoring every active candidate against every open role, which is a product of two numbers that both grow when the business is doing well.

A bigger machine buys a few months. The real fix is to refuse to score most of the pairs. Cut the candidate set with cheap indexable predicates first (location, right to work, seniority band, availability), run the expensive scoring over what survives, then cache the result with an invalidation rule tied to profile and role edits. Teams resist this because the cheap predicates make matching slightly worse at the margins. Slightly worse and returning beats ideal and timing out.

Notifications are a fan-out problem wearing a product hat

One employer posts one role. Forty thousand candidates match it loosely enough to be worth telling. That single user action becomes forty thousand emails, forty thousand push attempts and forty thousand rows. The queue swallows the first few thousand. The mail provider's rate limit handles the rest, and the platform's sending reputation absorbs the consequences.

Volume forces a product decision here, and it is better taken deliberately than discovered. Digest rather than immediate. A cap on per-candidate frequency. Ranking, so a candidate receives the three roles worth their attention rather than the forty that technically matched. This is usually presented to a client as an engineering constraint. It lands better as what it is: the mechanism that stops candidates muting the product, a failure state nobody has a dashboard for.

The database is doing two jobs

Most of these platforms run search and transactions on one store, because at the start that is obviously correct. Then a candidate updates a profile, which touches the search index, the match cache, the recommendation features and three denormalised counters, and one edit becomes a write storm. Recruiters meanwhile run long analytical queries across the same tables during working hours, which is when the write load also peaks.

Splitting the read path is the standard answer and carries its own cost. Replication lag becomes visible, and a recruiter who cannot see the candidate they added thirty seconds ago has no interest in eventual consistency. Make that call consciously and put the staleness window in front of the user rather than leaving them to find it during a client call.

The job nobody is watching

The failure we see most often is none of the above. It is a nightly batch that recomputes something, was written when it took twenty minutes, and now takes nine hours. Nobody watches it, because it has always finished before anyone arrived. Then one morning it has not, the search results are a day stale, and by the time somebody diagnoses it the platform has been quietly wrong for a week.

Instrument the batch as though it were a user-facing endpoint. Duration, row counts, and a hard alert when the run time crosses a set fraction of the window it has to fit inside. A job with no headroom left is a scheduled outage with a date on it.

Automation pushes load into the weakest part

We worked with a rapidly growing technology firm whose manual hiring process had become the constraint on its growth, and put AI-driven sourcing, automated screening and scheduling in front of it.

That result only held because the platform underneath could carry the volume the automation created. Widening the top of a hiring funnel sends more candidates into precisely the components that scale worst. A sourcing engine that triples the candidate pool triples the matching cost and the notification fan-out on the same afternoon. Size that before the automation goes live, not during the week it does.

The scaling wall is almost never a moment. It is a decision taken eighteen months earlier, when scoring every candidate against every role was the simplest thing that worked, and it genuinely was.