---
type: "post"
id: "translations-at-scale-memory-optimization-techniques-that-kept-92ffbb"
slug: "translations-at-scale-memory-optimization-techniques-that-kept-92ffbb"
title: "Translations at Scale: Memory Optimization Techniques That Kept Uber's P99 Under 1ms"
description: "Uber’s case shows that reducing garbage-collection overhead and reducing the resident data set are separate optimization problems."
retrieval_nugget: "Uber’s case shows that reducing garbage-collection overhead and reducing the resident data set are separate optimization problems."
published_at: "2026-10-17"
updated_at: "2026-10-17"
record_date: "2026-10-17"
date_kind: "published_at"
topics: ["memory"]
source_urls: ["https://www.uber.com/us/en/blog/translations-at-scale"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:translations-at-scale-memory-optimization-techniques-that-kept-92ffbb"
status: "published"
visuals: []
editorial_provenance: {"schema_version":"newruntime-editorial-copy-v1","content_status":"source_grounded_final","final_copy_sha256":"sha256:e4ad27da8ce861795ddf055297db70c7df81af375e6d5c15431d18c85e4a7695","reviewed_at":"2026-10-17T00:02:40.550Z","source_evidence_count":1,"verified_claim_count":2,"site_analysis_schema_version":"newruntime-site-analysis-v1","site_object_kind":"field_note","observed_fact_count":2,"implication_count":1,"watch_condition_count":1,"related_record_count":0}
analysis: {"schema_version":"newruntime-site-analysis-v1","object_kind":"field_note","thesis":"Uber’s case shows that reducing garbage-collection overhead and reducing the resident data set are separate optimization problems.","observed_facts":[{"text":"Uber says replacing sync.Map with a map guarded by an RWMutex reduced CPU usage by more than 30% for the service discussed.","source_urls":["https://www.uber.com/us/en/blog/translations-at-scale"]},{"text":"In the example, memory fell from about 2.7 GB to 750 MB and the cache hit ratio exceeded 99.9%.","source_urls":["https://www.uber.com/us/en/blog/translations-at-scale"]}],"mechanism":"The service kept compact hash-based metadata and hot entries in memory while placing other translation values on disk, using sharding, eviction, and selective preloading to manage contention and latency.","why_now":"Why now: memory and garbage collection remain production costs even when the application’s core data is simple key-value content.","implications":["The implication is that cache design should be evaluated against both allocation pressure and the resident working set, not just lookup speed."],"evidence_boundary":"The evidence boundary is Uber’s own workload and reported measurements; the post does not provide independent validation or a general benchmark across services.","watch_conditions":["Watch whether the disk-backed design preserves latency and hit rate as translation usage and repository size grow."],"related_records":[],"new_branch_reason":"No prior New Runtime record was supplied for this specific translation-service memory optimization case."}
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/translations-at-scale-memory-optimization-techniques-that-kept-92ffbb/","markdown":"https://newruntime.com/posts/translations-at-scale-memory-optimization-techniques-that-kept-92ffbb.md","json":"https://newruntime.com/posts/translations-at-scale-memory-optimization-techniques-that-kept-92ffbb.json"}
---

# Translations at Scale: Memory Optimization Techniques That Kept Uber's P99 Under 1ms

## Retrieval answer

Uber’s case shows that reducing garbage-collection overhead and reducing the resident data set are separate optimization problems.

Uber’s case shows that reducing garbage-collection overhead and reducing the resident data set are separate optimization problems. The first change targeted allocation structure; the later hybrid design addressed how much translation data stayed in memory. This is an operational case study, not evidence that a disk-backed cache is the right default for every service.

The mechanism was to keep compact hash-based metadata and hot entries in memory while placing other translation values on disk, with sharding, eviction, and selective preloading used to manage contention and latency. The service kept compact hash-based metadata and hot entries in memory while placing other translation values on disk, using sharding, eviction, and selective preloading to manage contention and latency. Uber reports that replacing `sync.Map` with a map guarded by an RWMutex cut CPU usage by more than 30% in the service discussed. In its example, memory fell from about 2.7 GB to 750 MB, while the cache hit ratio remained above 99.9%.

Why now: memory and garbage collection remain production costs even when the application’s core data is simple key-value content. The implication is that cache design should be evaluated against both allocation pressure and the resident working set, not just lookup speed. The evidence boundary is Uber’s own workload and reported measurements; the post does not provide independent validation or a general benchmark across services. Watch whether the disk-backed design preserves latency and hit rate as translation usage and repository size grow.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Memory](https://newruntime.com/topics/memory.md): Explore the memory topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Source Ledger](https://newruntime.com/source-ledger.json): Inspect the public source evidence graph.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)