How teams scaled S3: 2 real case studies
2 of the 94 engineering write-ups in our database mention S3 in their stack. They come from 2 companies (Notion and Pinterest) and were published between 2024 and 2026. 1 of the 2 state concrete scale numbers, for example "up to 32% faster end-to-end evaluation" (Pinterest). Each card below links to our short summary and the original post.
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.
Building and scaling Notion's data lake
Notion replaced slow warehouse syncs with a CDC pipeline (Debezium to Kafka to Hudi on S3) processed with Spark.