Feed sharding

To shard a feed is to break the whole feed into multiple non-intersecting subsets. Depending on your backend systems, fleet types, and sizes, sharding might be necessary.

When to shard

  • If the feed's size is too large, as this can cause performance problems when the partner tries to follow the data freshness requirements.

  • The partner's backend system has technical difficulties with combining fleet information across systems in different countries.

  • To prevent sharding from compromising the system's performance, we recommend the following for each micromobility system:

    • Dockless: Sharding is discouraged but allowed. We highly recommend that you keep the number of shards to a minimum and make each shard as large as logically possible.

      Each shard must cover a geographical service area at least the size of a metro area or larger. For example, while Google allows a shard to contain only a single metro area such as New York city, large shards such as one that covers the entire EMEA region are preferred.

    • Docked: Sharding is allowed and partners are encouraged to shard the feed by metro areas.

General rules

  • Each shard must contain a complete set of GBFS files that can fully describe the system and can be used independently.

  • All relevant information must be contained in a single shard and no cross referencing is allowed with other shards. For example, a dockless vehicle in Shard A can't reference a system pricing plan from Shard B. Instead, its pricing plan must be defined within Shard A.

  • All shards must be non-intersecting. In the event that a dockless vehicle or docked station is presented in two different shards, it is treated as two separate entities, and the duplicate information will be presented to users.

  • Geofences defined in one shard must not overlap geofences defined in a separate shard.

  • Geofences must not utilize anti-clockwise arrangement referencing to areas outside of polygon.