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.