Feed sharding
Stay organized with collections
Save and categorize content based on your preferences.
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.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-04-02 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-04-02 UTC."],[[["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."]]],["Sharding a feed divides it into non-overlapping subsets, which may be necessary for large feeds or backend limitations. Dockless systems should minimize shards, making each cover a metro area or larger. Docked systems can shard by metro area. Each shard must be self-contained, with no cross-referencing, and any duplicates across shards will appear as separate entities. Geofences in different shards cannot overlap and must have a clockwise arrangement.\n"]]