Loading…
Browse by type
Problem & solution reads
Problem & solution posts on Yomu, summarised newest first.
- 891 posts
- 20 companies
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Problem & solution posts
How we seamlessly migrated high volume real-time streaming traffic from one service to another with zero data loss and duplication
Grab migrated its stream-processing (write) functionality from an existing service into a separate service while handling 20,000 reads per second from 16 Kafka streams and writing to output streams and DynamoDB tables. The migration required gradual stream-by-stream rollout, production validation, and a no-downtime switchover; feature flags were rejected because deployment timing could cause loss, duplication, or inconsistent values. The team moved processing into shared /commons code, created temporary validation sinks, and scheduled each switchover with a shared map[string]time.Time, allowing both services to change writers at the same time. During each cutover, both services consumed streams, the old service stopped writing to resources, and monitoring continued before old consumption was removed; the result was zero data loss or duplication, no downtime, and completion in about three weeks. It was temporary and tested, but rolling back either service could create inconsistency if systems fell out of sync.
Supercharging LLM application development with LLM-Kit
Grab developed LLM-Kit, a comprehensive framework for setting up production-ready Generative AI applications while addressing security, scalability, integration, monitoring, and standardisation concerns. Its pre-configured structure includes an API server, configuration management, a sample LLM Agent, tests, and an integrated stack spanning Poetry, Gunicorn, FastAPI, LangChain, LangSmith, HashiCorp Vault, Amazon EKS, and GitLab CI. Engineers submit application details through a form, which triggers GitLab project and code-scaffold generation, CI/CD setup, Terraform-based staging and production infrastructure provisioning, and secure GPT-token storage in Vault. The scaffold also includes authentication, API documentation, observability, Redis and vector-database integrations, deployment pipelines, and a cookbook with organisational examples; the post reports that it has onboarded hundreds of GenAI applications and saves an estimated 1.5 weeks before teams begin their first feature.
How Tinder Eased Development Pain With Ignis
Managing hundreds of microservices with disparate configurations forced Tinder engineers to deploy code to staging environments to verify every change, slowing development velocity. To shorten feedback loops, the team created Ignis, a Go-based CLI tool that lets engineers run an isolated service locally while proxying ingress and egress traffic through a multi-tenant development Kubernetes cluster. Ignis pairs with an API gateway for client testing and uses a custom Smart Router proxy to dynamically intercept downstream gRPC and HTTP requests via Kubernetes informers and header propagation. Since launching in 2019, the tool enabled Tinder to eliminate a dozen staging environments, decrease cloud spend, and accelerate onboarding, followed by a V2 release adding remote IDE support and monitoring.
Metasense V2: Enhancing, improving and productionisation of LLM powered data governance
Metasense V2 addresses automated data governance by improving an LLM-powered metadata generation and classification system. It builds on an initial rollout that scanned more than 20,000 data entries at 300–400 entities per day, but retained human verification to catch misclassifications. Post-rollout owner feedback and manual classifications from the Data Governance Office supplied training and testing data, exposing failures involving PII in business email columns, nested JSON, and passenger communications. The revised approach splits PII and non-PII tagging, reduces the PII tag set from 21 to 8, shortens the prompt from 1,254 to 737 words, and divides tables exceeding 150 columns. LangChain and LangSmith support prompt development, evaluation across accuracy, latency, and error rate, deployment, and monitoring, while threshold-based alerts trigger a model-improvement protocol when misclassification rates rise.
How we reduced peak memory and CPU usage of the product configuration management SDK
GrabX’s product configuration SDK used substantial memory and CPU because every client downloaded, decoded, and loaded a single JSON file containing configurations for all services, even when it needed only a small subset. The design also regenerated and fetched complete files every minute, while decoding a file larger than 100 MB could starve request handling and increase P99 latency. The proposed redesign partitions data by service, stores each configuration in its own JSON file and S3 prefix, and adds service-level changelogs so SDKs subscribe only to required services and apply targeted updates. Benchmarking across varied configuration sizes found potential reductions of up to 70% in memory utilisation and more than 50% in maximum CPU utilisation. Further work is planned to reduce SDK initialisation time.
Leveraging RAG-powered LLMs for analytical tasks
Data analysts at Grab faced an increasing volume of stakeholder data requests that required manually writing and executing repetitive SQL queries with minor parameter changes. To automate routine tasks like metric reporting and fraud investigations, the Integrity Analytics team paired an internal prompt-management platform, Spellvault, with Data-Arks, an in-house Python-based middleware that packages SQL queries and Python functions into APIs. A scheduler triggers automated report summarization, while an analytical bot named A* bot executes relevant investigation queries via RAG and returns summarized findings in Slack. Automated report generation saves an estimated three to four hours per report and shortens multi-query fraud investigations to minutes. Grab favored RAG over fine-tuning because it avoids continuous retraining costs, scales faster across diverse use cases, and surfaces current production data.
Improving Compute Sustainability: A Case Study
Two Sigma's large computing footprint drives significant energy consumption and carbon emissions, particularly across live trading applications that require continuous real-time market data caching. To address this overhead without sacrificing performance, engineering teams used a routine hardware refresh to transition from legacy single-process machines to denser multi-core server configurations. By replacing roughly 60 legacy hosts with 28-core processor hardware, the team distributed baseline power draw over more cores and eliminated underutilized compute capacity. This architectural consolidation reduced absolute power consumption across production hosts by 66%, dropping electricity usage from 27 MWh in January 2023 to 10 MWh in January 2024. The initiative subsequently established an annual sustainability rationalization practice for hardware budgeting across the organization.
Evolution of Catwalk: Model serving platform at Grab
Grab developed and scaled Catwalk, an internal machine learning model serving platform, to address operational bottlenecks, low resource utilization, and deployment friction between data scientists and backend engineers. The platform transitioned from an admin-managed TensorFlow Serving setup into a low-code self-service system supporting PyTorch and ONNX, before replacing complex Helm charts with Kubernetes Custom Resource Definitions for declarative, blue-green deployment orchestration. To support complex business workflows and multi-model applications, Grab subsequently introduced Catwalk Orchestrator with bundled deployments that allow individual services to scale independently. Across two years, the orchestrator architecture expanded to 200 deployed applications serving approximately 1,400 production machine learning models.
Enabling conversational data discovery with LLMs at Grab
Grab faced major bottlenecks in dataset discovery across its 200,000 data lake tables due to low documentation coverage and vanilla Elasticsearch limitations in its internal tool, Hubble. To resolve this, engineers first tuned Elasticsearch by boosting frequently queried P80 tables and certified schemas while deboosting deprecated datasets. They then deployed a GPT-4 pipeline that generated documentation from table schemas and sample data, raising P80 documentation coverage from 20% to roughly 90%. Finally, the team developed HubbleIQ, an LLM-powered assistant built via Glean Apps and integrated into Slack and Hubble search to answer semantic queries. These initiatives increased search click-through rates to 94% and lifted the proportion of users finding discovery easy to 73%.
Bringing Grab’s Live Activity to Android: Enhancing user experience through custom notifications
Grab designed an equivalent to iOS Live Activities for Android to provide real-time order tracking outside the app. Because Android lacks Apple's native ActivityKit push token system, the team substituted push tokens with placeholder values to maintain technical consistency across platforms and preserve backend push targeting via their Hedwig service. For the user interface, engineering selected custom notifications over floating views because custom notifications avoid intrusive screen usage and do not require the 'Draw over other apps' permission. The client implementation separates responsibilities across dedicated classes: LiveActivityIntegrationManager handles token registration across business verticals, LiveActivityAttributes encapsulates UI configuration, and LiveActivityManager maps payloads to Android NotificationManager instances. The solution launched for Food, Mart, Express, and Transport verticals.
Upgrading your Stripe plugin security
Stripe plugins commonly authenticate merchants’ accounts with unrestricted secret API keys, but those keys grant full access and can expose payment, customer, and subscription operations if mishandled or compromised. The post presents restricted API keys (RAK) and OAuth 2.0 as zero-trust alternatives that apply identity verification and least-privilege permissions to third-party integrations. RAKs let developers define narrowly scoped permissions, while OAuth 2.0 uses Stripe’s interface for tokenized, one-click authorization and lets merchants revoke access without sharing a secret key. For existing plugins, it outlines migration through Stripe Apps, Stripe Connect, or manual RAK setup, and states that Stripe will require RAK or OAuth 2.0 authentication from October 29, 2024, with possible fees for merchants still using full-access keys after June 2025.
Tophat: Crafting a Delightful Mobile Developer Experience
Shopify built Tophat to reduce the time and friction involved in manually testing mobile pull requests, where switching branches, stashing changes, and waiting for Xcode or Android Studio builds slowed review. The macOS menu-bar application links GitHub pull requests to iOS and Android artifacts produced by CI and stored in Google Cloud Storage, allowing contributors to install builds on simulators or real devices with one click. Tophat parallelizes tasks such as downloading applications and booting devices, and its Quick Launch feature retrieves builds with up-to-date native code for React Native development. The project also addressed real-device iOS installation and signing challenges, integrated with Shipit Mobile, and provided automated setup guidance. After the latest improvements, daily usage doubled, and Tophat was later made open source.
Mitigating Deadlocks in high concurrency environments
MySQL requires locks before updating existing records, and concurrent upserts that mix new and existing rows can deadlock when gap locks overlap, even when processes target different records. The post describes ETL jobs partitioned by account whose updates nevertheless contend because sequential primary-key ordering places records in shared index gaps. It proposes replacing the existing primary key with a composite key of account and id, aligning InnoDB's physical row ordering with the processes' update partitions; gap locks remain necessary, but are largely compartmentalized within each process. An additional unique index on id preserves standalone record identification and compatibility with existing joins, while application and ETL logic remain unchanged. The reported outcome was removal of artificial delays and significantly higher import throughput through reduced job wait time.
Improving Retrieval on Ramp with Transaction Embeddings
Ramp developed transaction embeddings to help automate accounting coding, where employees choose general ledger (GL) categories for transactions. The model represents enriched transaction features—such as merchant, category, department, location, amount, memo, spend program, and trip—as stringified documents labeled with chart-of-accounts codes. Starting from a pre-trained encoder, it is fine-tuned with sentence-transformers and BatchSemiHardTripletLoss, using large batches and contextual sampling to learn embeddings whose similarity is measured with cosine similarity. Triplet loss pulls same-label transactions together and pushes different-label examples apart, while informed mining addresses subtle distinctions such as Travel: Sales versus Travel: Engineering. The embeddings support GL coding suggestions, high-confidence defaults, business-spend similarity analysis, and transaction context for LLM-enabled features, with the stated aim of keeping predictions personalized and data private.
How we improved translation experience with cost efficiency
Grab faced translation quality and cost challenges in its booking chat system when tourism resumed after COVID restrictions eased. Device language settings proved unreliable for determining message language, prompting the team to use Lingua alongside booking context heuristics and third-party fallbacks for real-time detection. To replace expensive and inaccurate general translation APIs, Grab distilled a large open-source Hugging Face model into lightweight, language-specific models trained on ten million synthetic chat examples. A post-translation validation step verifies non-translatable entities such as numbers and emojis before falling back to external services if mutations occur. Caching layers were also introduced across translation paths to curb redundant on-the-fly execution.
Making Machines Move
Fly.io needed to restore the ability to drain physical workers after attached NVMe volumes made stateful Fly Machines tied to particular servers. Snapshot restoration could lose data, while killing a machine before copying its volume caused unacceptable downtime; copying first risked losing writes. The solution was an asynchronous clone operation built around Linux device mapper’s dm-clone: a new volume is created immediately, reads of unhydrated blocks are fetched from the original over iSCSI, writes go to the destination, and background copying rehydrates the rest. The work also required orchestration across flyd and a fix for Fly Postgres configurations containing literal 6PN IPv6 addresses. After cautious early migrations, the infrastructure team could drain hosts without much ceremony by summer 2024, though routine automated rebalancing remained a future goal.
LLM-powered data classification for data entities at scale
Grab needed to classify sensitive data at the table and column level across petabytes of database tables and streaming schemas. Manual schema-tiering campaigns had resulted in half of all schemas receiving overly strict Tier 1 access controls, while an initial automated service using regex patterns and third-party machine learning produced high false-positive rates and lacked customizability. To address this, the Caspian data engineering and governance teams enhanced their internal orchestration service, Gemini, by integrating GPT-3.5 via Azure OpenAI. Gemini aggregates classification requests into mini-batches, handles API rate limits, and uses prompt engineering—including few-shot examples, curated tag libraries, and explicit JSON DTO schemas—to reliably tag columns for data owner verification.
AWS without Access Keys
The post describes how Fly Machines can access AWS resources such as an S3 bucket without distributing long-lived AWS access keys. It uses OpenID Connect (OIDC): AWS IAM trusts Fly.io’s OIDC identity provider, a role grants narrowly scoped permissions, and the app receives the role ARN as an environment variable. At boot, Fly’s Rust init requests a machine-specific OIDC token through the /.fly/api Unix socket, writes it to /.fly/oidc_token, and sets AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_SESSION_NAME so the AWS SDK can call STS AssumeRoleWithWebIdentity. AWS verifies the token, issues short-lived credentials, and evaluates the role’s IAM policy before serving the requested object. The trust policy can constrain tokens by audience and subject, including an organization, Fly App, or machine; the same pattern can authenticate against other OIDC-compliant providers, although Azure and GCP lack equivalent init integration.
Make Better Decisions by Embracing Uncertainty
Ramp uses multi-armed bandits to choose among third-party bank-linking providers when provider performance varies by financial institution and available data is noisy, incomplete, or stale. Instead of maintaining separate, static A/B tests, it applies Thompson Sampling, modeling each provider’s success probability with a Beta distribution and repeatedly sampling, routing traffic to the highest sampled value, then updating the model from the result. Simulations examined changing success-rate trends, noise, volume, rolling-window size, trend type, and initial conditions; the algorithm generally exploited clearly better providers, split traffic more evenly when rates were close, and recovered eventually from incorrect starting conditions. In a sequential quasi-experiment, Thompson Sampling increased financial-institution linking success by 10% and reduced customers with manually uploaded bank statements by 25%.
How we evaluated the business impact of marketing campaigns
Grab needed a scalable, centralised way to evaluate the business impact of millions of marketing messages sent across expanding campaigns. Manual analysis by marketing analysts produced inconsistent results and failed to scale, leading to the creation of multi-touch attribution and controlled experiment methodologies. The team designed a Marketing attribution model (MAM) that credits touchpoints based on relevance and recency, while using stratified hold-out groups to assess single campaign lift against baseline metrics. Statistical significance calculations, implemented using the jStat library based on the central limit theorem, ensure observed business metric differences like gross merchandise value are not random. The system provides campaign managers with direct access to impact analyses while the team works on challenges surrounding smaller sample sizes and hold-out group constraints.
Top topics
- Architecture830
- Performance812
- LLMs648
- Machine Learning617
- Open Source561
- AI Agents542
- AI454
- Developer Experience446
Weekly digest
The best engineering reads, once a week.