How We Reduced GrabX SDK Initialisation Time
Article Summary
Grab's SDK was taking 4 minutes to initialize with 400MB of config data. That's a cold start problem that kills autoscaling.
Grab's engineering team tackled their GrabX SDK initialization bottleneck through a phased optimization approach. GrabX is their central platform for product configuration management, serving configs to client services across their superapp ecosystem.
Key Takeaways
- Phase 1: Parallelized subscribed and common data loads (80% faster)
- Phase 2: Concurrent downloads for large config files (6% additional improvement)
- Phase 3: Removed disk persistence that conflicted with fresh data requirements (50% faster)
- Final result: Up to 90% reduction in initialization time across services
A three-phase optimization reduced SDK initialization time by up to 90% by parallelizing loads and eliminating unnecessary disk persistence.
About This Article
GrabX SDK clients took a long time to initialize. Services that handled high traffic volumes couldn't scale properly because cold starts lasted several minutes, which caused the system to throttle when demand spiked.
Grab's engineering team made three changes to fix this. They parallelized how subscribed and common data loaded. They also enabled concurrent S3 downloads for large configuration files. Finally, they removed disk persistence that was getting in the way of loading fresh configuration data.
These optimizations cut SDK initialization time by up to 90% across services with different configuration data sizes. The faster startup times let autoscaling work better and made services more reliable under load.