Skip to main content
← All case studies
EdTech InfrastructureEdTech·PSI Services LLC

RSaaS: Resource Scheduling as a Service

A unified exam scheduling API that abstracts booking complexity behind one integration, with caching and a hold-and-confirm workflow that prevents double-booking.

GoReact/TypeScriptPostgreSQLRedisREST APIDocker
PSI Services LLC logo

The Problem

Enterprise exam scheduling integrations were expensive and slow to deliver because each client required complex orchestration work. Legacy booking dependencies increased implementation risk and extended onboarding timelines. Teams needed a stable API layer that reduced integration overhead.

The scheduling domain itself is unusually intricate. Candidates with accommodations need adjusted exam durations, availability must reflect real-time capacity across geographically distributed test centers, and concurrent booking attempts on the same slot have to be resolved without creating conflicts. Every new client integration re-solved these same problems from scratch.

What We Built

We built a unified scheduling API that abstracts booking complexity and exposes consistent orchestration workflows for client implementations. The service includes reliability controls, caching strategy, and client-specific process support where needed. This created a reusable integration foundation instead of one-off builds.

The API sits in front of the underlying booking system and presents a stable contract that does not change when the backend does. A caching layer absorbs the high volume of availability lookups that would otherwise hit the upstream system directly, and a two-phase booking workflow makes double-booking structurally impossible rather than merely unlikely.

Unified booking abstraction

One consistent REST contract covers test center search, slot availability, holds, and confirmation—replacing bespoke per-client integration work against the underlying booking system.

Two-phase hold-and-confirm

Selecting a slot places a time-limited hold that makes it immediately unavailable to others, so a candidate completing checkout cannot lose the slot mid-flow or collide with a concurrent booking.

Redis availability caching

A caching layer absorbs the bulk of availability lookups, keeping responses fast under load and protecting the upstream booking system from redundant query volume.

Accommodation-aware scheduling

Candidate accommodations translate into adjusted exam durations before availability is calculated, so returned slots genuinely fit the candidate rather than the default exam length.

How It Works in Practice

A candidate with an approved time-extension accommodation scheduling a professional certification exam near their workplace.

  1. 1

    Find nearby test centers

    The candidate enters a postal code and search radius. The service validates the request, applies the accommodation to compute the true exam duration, and returns nearby centers ranked by distance.

  2. 2

    Check real availability

    Selecting a center returns time slots that can actually accommodate the extended duration—not generic openings that would fail at booking time.

  3. 3

    Hold the slot

    Choosing a time places a short-lived hold. The slot immediately reads as unavailable to other candidates, giving this one room to complete checkout without racing anyone.

  4. 4

    Confirm the booking

    Confirmation converts the hold into a reservation. If the candidate abandons checkout, the hold simply expires and the slot returns to the pool automatically.

Engineering Approach

An abstraction layer, not a passthrough

The API presents its own stable contract rather than mirroring the upstream booking system, so client integrations survive changes to the system underneath and each new client reuses the same interface.

Caching sized to the read pattern

Availability lookups vastly outnumber bookings, so a cache layer absorbs that read volume with short expiry windows—keeping responses fast while ensuring slot data never drifts far from reality.

State that expires on its own

Holds are stored with a built-in expiry rather than requiring cleanup jobs, so an abandoned checkout releases its slot automatically without background reconciliation or manual intervention.

Have a similar problem?

Tell us what you're working on and we'll tell you honestly whether we can help.

Copyright © 2026 Datum Brain

facebookinstagramlinkedintwitteryoutube