Feed sharding

  • Sharding breaks down large data feeds into smaller, independent subsets to improve performance and address system limitations.

  • Sharding is recommended for large feeds or when a partner's system has difficulty combining data from different locations.

  • Each shard must contain complete and independent information, with no cross-referencing between shards allowed.

  • Overlapping geofences and anti-clockwise referencing in geofences across shards are prohibited.

  • Dockless systems should minimize shard numbers while docked systems are encouraged to shard by metro areas.

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 (greater than 50MB), 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: We 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.

    • 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.