How we reduced peak memory and CPU usage of the product configuration management SDK
Article Summary
Grab's configuration management SDK was crushing service performance with memory spikes and CPU throttling. 98% of services were loading 100x more data than they actually needed.
The Grab engineering team tackled their GrabX SDK's resource consumption problem that was blocking wider adoption across their 700+ city superapp platform. They analyzed how services were reading configuration data and found massive inefficiencies in their monolithic JSON approach.
Key Takeaways
- 70% reduction in memory usage by partitioning configs per service
- 50%+ drop in CPU utilization through service-based data subscriptions
- Separate JSON files per config unlocked 5,500 reads/sec per prefix
- Service-level changelogs eliminated full file downloads every minute
- P99 latency spikes eliminated by avoiding CPU starvation during decoding
By shifting from a single monolithic JSON file to service-partitioned configs with changelogs, Grab cut SDK memory usage by 70% and CPU by over 50%.
About This Article
The GrabX SDK required clients to download and decode a single JSON file over 100MB in size every minute. This file contained configurations for all services, but 98% of services only needed less than 1% of the data. The large downloads caused CPU throttling that pushed P99 latency higher.
Grab split the configuration data into separate JSON files organized by service. They also added service-level changelog files so SDKs could subscribe to only the services they needed and pull incremental updates instead of downloading the full file each time.
Memory utilization dropped by up to 70%. Maximum CPU utilization fell by more than 50%. The system now handles 5,500 read requests per second per configuration prefix on S3.