Figma · 2026
How Figma manages sandboxes at scale
Figma's AI products needed secure places to run untrusted code, so the team built Nimbus, a centralized sandbox platform that product teams call through a simple namespace config and GetOrCreate/Get/Delete APIs. Nimbus picks a cloud provider, applies networking and security policies (trusted-host allowlists plus read-only GET/HEAD/OPTIONS to the rest of the internet, credentials decrypted only on the way out to their intended destination), and runs sandboxd inside each box for process supervision and metrics. Warm pools of already-running sandboxes cut provisioning latency by about 90% versus cold starts, raised availability from 99% to 99.95%, and absorb minutes of provider outages while Postgres claim transactions and a Redis health-check queue keep the pool correctly sized and singly assigned.
tens of thousands of sandboxes across productswarm pools cut provisioning latency ~90%warm poolsmulti-provider failovernetwork policy isolationNimbusPostgresRedis
Pinterest · 2026
Scaling Model Evaluation at Pinterest with Ray (Part 4)
Pinterest's feature-importance and multi-experiment evaluation used to run Ray inference, write predictions to S3, then start a separate metrics job that reread everything. They defined a ReducibleMetric contract (dataset_preprocessor, compute_partials, reduce_partials) so MAE, threshold-based ROC-AUC, and group-wise Precision@K can all compute from batches or segment-preserving buckets, then fused metric reduction into the Ray inference pass via the shared object store. On a Pin Ranking Model, fusion cut end-to-end wall-clock time by up to 32% (25–32% at 100 experiments across ≈30K–3M row sets) and kept Large-set runtime roughly linear (~43 min fixed plus ~41s per experiment up to 300), absorbing a separate ~11s-per-experiment metrics stage.
up to 32% faster end-to-end evaluationLarge eval set ≈3M rows (also ≈30K / ≈300K)fused inference and metricsreducible metricsbatch inferenceRayApache SparkS3
Meta · 2026
F3 Lightning: How Meta Accelerates Ads ML Features to Production at Scale
Meta's Facebook Feature Framework (F3) compiles ads ranking features into one merged DAG so shared work runs once, but that graph was also the release unit, so one bad definition blocked every other feature as the catalog grew past 20,000 features per request. F3 Lightning makes each feature an independently compiled, validated, deployed, and rolled-back configuration, then rebuilds shared execution at service startup: stable identifiers derived from each computation's meaning, one flattened execution plan that deduplicates common nodes, a single per-request memory buffer, and dense integer slot mapping so request-path reads are direct array indexes. Comparable extraction features now reach production about 3.6x faster than traditional F3 with no increase in infrastructure compute cost.
20,000+ features per ads ranking request~3.6x faster feature releases to productionper-feature releaseshared execution planstable computation identifiersF3DAG feature graphsAds ML