Democratising Fare Storage at Scale Using Event Sourcing

Summary

Grab's legacy system stored booking and fare details in a single relational table, creating a bloated booking entity that tracked only the latest fare state and hindered rapid feature iteration. To resolve scalability, stability, and debugging challenges across millions of daily bookings, the team developed Fare Storage using the Event Sourcing pattern. The new architecture persists all fare modification events chronologically in DynamoDB, backed by a cache for eventually consistent reads and message streaming for downstream processing. The platform employs optimistic locking with versioning to manage concurrent updates, enforces idempotency through client-generated transaction UUIDs, and delegates metadata serialization to an SDK to prevent storage API changes.

Takeaways

1. 1

   Optimistic locking using incremented version numbers prevents race conditions during concurrent fare updates while offloading fare recalculation logic to client services.

2. 2

   Idempotent event processing is maintained by having the client SDK generate a unique transaction UUID per event, enabling the store to reject duplicate retry submissions.

3. 3

   Serializing metadata into raw bytes at the client SDK layer allows product teams to introduce new fee breakdowns without deploying updates to the central storage service.