All work
Enterprise Integration PlatformIn productionFull stack engineer

A two-way sync between a collaboration suite and an IT service system, with an admin console to map people and watch sync status.

  • Calls are no longer invisible

    A technician on a Teams call now shows as busy to managers, and the call is on record in the ticketing system.

  • The same availability everywhere

    Dashboards, calendars, bookings and the ticketing system all show the same work availability and booked slots for each technician and employee.

  • Sync you can see

    A dashboard gives a complete view of the logs: which events synced, which did not, and why.

Client and edge

  • Next.js admin console
  • TLS proxy

Application

  • Node.js
  • TypeScript
  • GraphQL

Cache and queue

  • Redis
  • RabbitMQ

Data

  • PostgreSQL

Integrations

  • Microsoft Graph API
  • Teams, Bookings, Outlook
  • Ticketing system API

Step through a request one hop at a time, or switch to Trace and break to see which flows a service takes part in.

CLIENT AND EDGEONE NODE.JS PROCESSCACHE AND QUEUEDATAEXTERNALWeb UINext.js adminProxyTLS, routingGraphQL APIJWT, entitiesScheduler6 jobs, locksForward syncQueue consumersReverse syncQueue consumerCacheLocks, tokenQueue4 queuesDatabasePostgresTeamsCall recordsBookingsAppointmentsOutlookCalendar eventsTicketingPSA, REST API

The whole system. Pick a scenario, then step through it. The view zooms to the services each step involves.

  • Request
  • Sync
  • Jobs

  1. Sync

    Polling instead of webhooks

    Chose

    A scheduler polls each system for changes on a schedule, picking up everything since the last run.

    Rejected

    Webhooks, where each system pushes its changes to the platform.

    Why

    At this scale polling is convenient and stays well within every system’s rate limits. It needs no public endpoint for the other systems to call, and a missed run is made up by the next one.

  2. Jobs

    A distributed lock before every job

    Chose

    The scheduler takes a lock in the cache before each job and only then fetches.

    Rejected

    Starting every job without coordination.

    Why

    Only one run of a job is active at a time, even if more than one instance of the process is running, so the same change is not synced twice.

  3. Queue

    Queue the changes, then write them

    Chose

    Fetching only queues what changed. Separate consumers write each change to the other system.

    Rejected

    Writing to the target system inline while fetching.

    Why

    A slow or failing target does not hold up fetching, and each change waits in the queue until its consumer has processed it.