# Sync for GC Team Manager

DevFeed: [Sync for GC Team Manager](<https://devfeed.tech/articles/sync-for-gc-team-manager-19843.md>)

Original publisher: [Read original article](<https://tech.gc.com/sync-post-2/>)

Author: GameChanger

Published: 2018-01-25T14:10:50Z

Content type: article

Language: en

Sources: [GameChanger](<https://devfeed.tech/sources/gamechanger.md>)

Topics: [App](<https://devfeed.tech/topics/app.md>), [Messaging](<https://devfeed.tech/topics/messaging.md>), [Back end](<https://devfeed.tech/topics/backend.md>), [Algorithm](<https://devfeed.tech/topics/algorithm.md>), [Database](<https://devfeed.tech/topics/database.md>)

Tags: [app](<https://devfeed.tech/tags/app.md>), [article](<https://devfeed.tech/tags/article.md>), [backend](<https://devfeed.tech/tags/backend.md>), [build](<https://devfeed.tech/tags/build.md>), [database](<https://devfeed.tech/tags/database.md>), [messaging](<https://devfeed.tech/tags/messaging.md>), [sync](<https://devfeed.tech/tags/sync.md>)

## AI overview

This article explains how the GC Team Manager app implemented a synchronization system using backend Pub/Sub, asynchronous polling, and granular updates. It focuses on handling out-of-order messages, converting backend database changes into targeted sync topic updates, and iteratively moving from polling toward direct topic notifications.

## Source excerpt

Introduction In my last article I talked about the sync system for our new GC Team Manager app and the trade-offs we considered in our design process. To reiterate, the high-level structure we settled on was a backend Pub/Sub service, with small granular updates, and we needed to account for the lack of ordering in message delivery. In this article I will cover how we implemented and made this sync system work. I mentioned in the last post that part of the reason we settled on Pub/Sub was because we could use an iterative approach instead of all or nothing. This iteration broke down into two distinct parts, Asynchronous Polling Sync and Pub/Sub Sync. Asynchronous Polling Sync relied on Asynchronous Polling and topic updates. Pub/Sub Sync built device notification on top of Pub/Sub Sync. I will describe each in turn. Asynchronous Polling Sync The goal of Asynchronous Polling Sync was to solve a few distinct problems. First, it focused on building an algorithm that was resilient to out-of-order messages received by the devices. Second, it focused on turning backend database updates into targeted sync topic updates. To simplify the initial build, Asynchronous Polling Sync specifically avoided solving the problem of pushing topic updates to the devices themselves. It did this by allowing the devices to use Asynchronous Polling to get all updates. Switching from Asynchronous Polling to direct topic updates is the provenance of Pub/Sub Sync. I will cover each part of Asynchronous Polling Sync. Asynchronous Polling Sync Algorithm Handling Out of Order Messages When thinking about the out-of-order messaging problem, the goal is to ensure that no matter what order message are received in, all devices will end up in a consistent state. When we were thinking through possible ways to do this in our sync system, we realized that the type of message being sent can help you solve this problem. As a demonstration I will consider three types of updates the backend could send to the