Loading…
Latest reads
Every post, summarised
Grounded summaries of engineering blogs, newest first. Each links to the original.
- 4,671 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.
Latest posts
Mobile Bridge: Making WebViews Feel Native
Shopify’s mobile app has about 600 screens, but building every non-critical screen natively or in React Native was costly and slowed development, while conventional WebViews felt slow, disconnected, and out of place. Mobile Bridge addresses this hybrid-app problem with native iOS and Android modules that preload, authenticate, cache, and reuse WebViews, reducing P75 load time from 6 seconds to 1.4 seconds, including network latency and rendering. Built on @remote-ui/rpc, the framework uses JavaScript, CSS, Polaris overrides, title and action APIs, TransportableView, snapshots, and native modal transitions to preserve state and align web screens with native navigation and appearance. WebViews can also invoke native features such as date pickers, barcode scanning, and Add to Wallet; Shopify says the standalone library is being adopted across other products while critical features remain native or React Native.
Astronomy Geek to Oktanaut: Landing as a Dev Advocate at Okta
Akanksha Bhasin joins Okta as an “Oktanaut” in Developer Relations after more than six years building developer communities and four years focused on Developer Relations. Her path began with experiments in Arduino, programming, and AI applications, then shifted toward Voice AI after Google Assistant launched in 2018; she built applications for Google Assistant and Alexa and was later featured at Google I/O. She taught these technologies at meetups and colleges across India, founded Women in Voice, India, led Google Developer Groups, and helped organize events including DevFests that gathered more than 3,000 developers. At Okta, she wants to help independent software vendors and developers secure user identities, treating identity security and access management as foundational to enterprise applications rather than a checklist item.
Optimizing Stripe API performance in Lambda with caching strategies
The post addresses performance, cost, latency, and rate-limiting challenges that arise when applications make high-volume requests to Stripe's API from AWS Lambda. It presents a two-level cache using ElastiCache for Redis as the first layer and DynamoDB as the durable second layer, with Lambda coordinating cache reads, Stripe retrieval, and writes. On a miss, the function checks Redis, then DynamoDB, fetches the customer from Stripe if necessary, and stores the response in both layers with one-hour Redis and 24-hour DynamoDB TTLs. The DynamoDB design uses composite keys, a GSI for cache-type and timestamp queries, TTL cleanup, and environment-specific capacity settings; the post also discusses Redis connection pooling, Lambda sizing, capacity planning, cost control, monitoring, and webhook-based invalidation.
How to Add the Moesif API Observability Add-On to Your Heroku Applications
Heroku applications can add the Moesif API Observability add-on to analyze API traffic and support monetization. The setup uses either the Heroku CLI or Dashboard: the CLI command is heroku addons:create moesif, while the UI path goes through Resources, Find more add-ons, and Metrics and Analytics. Provisioning creates a MOESIF_APPLICATION_ID config variable, and the application then requires the Moesif SDK initialized with that value. The guide also covers copying the variable into a local .env file with Heroku Local and excluding that file from Git through .gitignore. Once configured, API events should flow into Moesif for live logs, time-series metrics, funnels, retention, alerting, and billing features, while Heroku handles add-on billing and user management.
Evaluating performance impact of removing Redis-cache from a Scylla-backed service
A Rust service at Grab serves tens of thousands of peak QPS for batched count requests, using Scylla, Redis, and MySQL counter configurations. Its 15-minute cache-key truncation and five-minute TTL caused cache-hit declines and recurring Scylla QPS spikes at the end of each quarter-hour, when recent-data requests generated new keys. The experiment progressively disabled Redis, while a daily major compaction job was added to Scylla nodes; the service continued combining minutely, hourly, and daily tables for range calculations. With Redis fully decommissioned, Scylla cache hits rose from about 30% to 70% of reads, cache misses stayed about the same despite doubled traffic, peak CPU moved from roughly 50% to 52%, and overall service performance was maintained while eliminating a component responsible for about 25% of service cost.
30 Minutes With MCP and flyctl
Kurt Mackey describes building a minimal MCP server for flyctl in 30 minutes, motivated by testing how an LLM could inspect deployed applications. MCP connects an LLM client to server-exported tools through JSON exchanges; this implementation uses stdio mode, a Go MCP library, and exposes only fly logs and fly status, producing roughly 90 lines of code. Existing JSON modes in flyctl commands made the tools easier to drive from automation. When pointed at unpkg through Claude, the server surfaced a globally distributed deployment, identified two critical machines, and connected repeated restarts and oom_killed events to Bun using about 3.7 GB of a machine’s 4 GB allocation. The post calls the result surprisingly useful while warning that local MCP servers give cloud-hosted Claude access to native programs and would be safer in isolation.
Because nobody likes being charged twice
Payment workflows can produce duplicate charges when a customer retries after a connection drop while the backend is still retrying the original request. The post frames network timeouts, crashes, database locks, downstream errors, and user interruptions as normal distributed-systems failures that can leave payment state uncertain. It recommends generating a unique idempotency key for one specific action, sending it with the Stripe request, and reusing it on every retry; Stripe recognizes the key for 24 hours and returns the original response. It also recommends placing payment jobs in a queue such as Amazon SQS, where workers retry failures and route repeatedly failing messages to a dead-letter queue. Together, queues preserve work during temporary outages and idempotency makes retries safe, while careful key scope and timing avoid stale or cross-operation behavior.
eBay Reduces the Time to List on Mobile With New Simplified Selling Tool, Now Featuring Magical Listing AI Technology
eBay has introduced a simplified, mobile-friendly listing flow that integrates its “magical listing” AI technology to reduce the effort required to create high-quality listings. Sellers start with photos and a title, while AI uses image matching and inference to suggest item specifics and categories through guided pages where sellers can review and approve the content. Early testing in the U.K. found a 50% reduction in total listing steps and faster listing times, while eBay says item-specific accuracy will continue improving through updates made during the year. The tool is available in the eBay mobile app for private sellers across all categories in the U.S., U.K., and Germany, and eBay plans to expand it to sellers using business tools.
Our Best Customers Are Now Robots
Fly.io reports that users driving the platform’s most recent growth are robots rather than people, prompting a reconsideration of developer experience (DX) as the primary product lens. The post describes how vibe-coding workflows use Fly Machines—Docker containers running as hardware-isolated virtual machines—to create, modify, stop, and rapidly restart environments without paying during stopped periods. These workflows favor incremental filesystem state, object storage, and controllable routing for MCP connections, including potentially long-lived SSE connections that should reach the same stateful instance. Fly.io also proposes exposing its API through MCP and using sealed, tokenized secrets so isolated machines can substitute real OAuth credentials only when needed. It concludes that a useful robot experience (RX) will require more than an MCP interface, while managed Postgres remains the company’s most important engineering priority and the platform is still primarily designed for humans.
Using an AWS microservice architecture for subscription management
Enterprise subscription management must handle mid-cycle plan changes, usage-based billing adjustments, synchronized service updates, atomicity, failed operations, data consistency, and auditability beyond basic recurring billing. This sample architecture uses an event-driven AWS design in which subscription changes are published to EventBridge and routed to Step Functions workflows. EventBridge provides at-least-once delivery, content-based filtering, dead-letter queue support, and integration with Step Functions, while Lambda functions validate changes, calculate Stripe proration, update external subscriptions, and trigger service-specific actions. Step Functions supplies retries with exponential backoff for StripeTemporaryError, DynamoDB stores current and historical subscription data using transactional updates, and Stripe calls use an event identifier as an idempotency key. The pattern is presented as a flexible foundation for reliability, maintainability, compensation for partial changes, and auditability in systems handling financial transactions and service provisioning.
Welcome Lena Waters, Notion’s new Chief Marketing Officer
Notion announces Lena Waters as its new Chief Marketing Officer while the company prepares to ship Notion Mail and enters a new phase of growth. Waters says she was attracted by Notion’s technical vision, user enthusiasm, mission, and volume of product releases, and brings experience from Grammarly and Docusign across consumer and B2B marketing, AI, IPO, acquisition integration, and multi-product expansion. She describes her operating theme as building scalable systems without sacrificing creativity, authenticity, or user connection. Her view of marketing’s AI role includes articulating a clear vision and roadmap, educating users, and collecting feedback as Notion AI changes how people work, think, and create. Her immediate priorities are listening, learning, meeting users, and understanding individual and enterprise customers.
Facilitating Docs-as-Code implementation for users unfamiliar with Markdown
Grab introduced a rich-text, WYSIWYG editor in its TechDocs portal to help non-engineering contributors work within a Docs-as-Code process despite limited familiarity with Markdown and GitLab. The editor keeps GitLab as the central storage system, uses Lexical to import and export Markdown, and supports page reordering, renaming, deletion, formatting, diagrams, and switching between normal and Markdown views. Three user journeys cover editing existing TechDocs and creating stand-alone or entity-linked documentation, with GitLab OAuth2, merge-request creation, repository access checks, and scheduler-based entity-catalog registration after merges. A phased rollout added drafts, image uploads, diagram integrations, concurrent-session visibility, and live preview, while pending-MR displays and conflict-resolution tools address collaboration risks.
Growth Intern to Procurement New Grad
A 2023 summer internship on Ramp’s growth engineering team changed the author’s view of software engineering and led to a return as a new graduate engineer. The team accelerated outbound sales through fast experiments, metric ownership, and decisions about whether promising tactics deserved scalable systems, rather than following the thorough specification process typical of regular projects. His work included reducing third-party data-enrichment costs, building AI-driven outbound-sales tools, adding observability and service monitors, and conducting competitive intelligence projects. He returned to join the new procurement product line, where he helped match card transactions to purchase orders and led additional projects. The post also recommends rapidly building system context through code review and on-call shadowing, while full-time engineers should weigh velocity against maintainability and take initiative on less-defined problems.
A Fall Internship at Ramp: Improving Reimbursements
During a fall internship at Ramp, a backend software engineering intern worked on the reimbursements team and describes projects that improved reimbursement flows while providing full-stack experience. One early change clarified multi-currency mileage reimbursements by showing both the expense currency and the payout currency, while later work overhauled mileage support with live navigation storage, frequent-trip recommendations, commute deductions, and automatic e-receipts. The post also discusses using LLMs to predict merchant categories from receipt text, enhancing merchant matching, and adding monitoring and alerts for OCR categorization errors. The reflection emphasizes measuring feature usage and outcomes, writing and revising specifications before implementation, leaving reusable code, and using Ramp’s transparent documentation and collaborative support. The internship concluded with a return to the University of Waterloo planned for 2025.
Tinder’s migration to Elasticsearch 8
Tinder modernized its recommendation system by migrating its core Elasticsearch infrastructure from an end-of-life Elasticsearch 6 deployment to Elasticsearch 8 on Kubernetes. The legacy setup relied on manual EC2 provisioning and custom scripts, preventing the engineering team from utilizing modern vector search capabilities while incurring substantial operational overhead. Tinder implemented Elastic Cloud on Kubernetes integrated with its in-house Infrastructure as Code framework, Scaffold, while refactoring custom Java ranking plugins to handle Elasticsearch 8 breaking changes like prohibited negative scoring. The migration was validated through offline benchmarking, online verification, and a three-wave A/B testing rollout. This transition completed with zero outages and under 0.2% data discrepancy, reducing p99 search latency by 12% to 56% and cutting annual infrastructure costs by over one million dollars.
Behind the Scenes - A Glimpse into Tax Calculations
As jurisdictions increasingly require marketplaces to collect and remit tax, Etsy describes the infrastructure it uses to calculate, record, and report taxes on transactions. When a buyer adds an item to a cart, Etsy sends a Quotation Request API call to Vertex, using buyer and seller locations, product category, tax rules, and mappings to determine the amount shown. At checkout and throughout fulfillment, DistributeTaxRequest SOAP calls carry order, cancellation, and refund details to Vertex, whose records support reporting and audit workflows imported into Etsy’s bigdata. The integration also required mapping Etsy taxonomy categories to Vertex rule drivers and separating quotation, distribution, and reporting workloads across multiple instances for horizontal scaling and load balancing. Shadow requests, ramped gradually without applying calculated taxes to carts, let the team simulate added Vertex load and monitor checkout performance before releasing traffic-increasing features.
Using GitHub Actions with Heroku Flow for additional Security Control
The pattern combines GitHub Actions with Heroku Flow for private repositories and stricter security requirements when GitHub organization IP restrictions cannot use Heroku IP ranges. A custom self-hosted GitHub Runner runs as a Docker image on Heroku, while the Platform API and Source Endpoint API upload source code to ephemeral storage, build and deploy apps, and manage Review Apps. Event-specific workflows handle pushes, manual runs, schedules, and pull requests; a weekly workflow rebuilds and autodeploys the runner image within GitHub’s 30-day update window. Setup uses a Heroku Private Space, its outbound IPs, a GitHub access token, and organization name, but omits the repository URL in the Review App UI, does not run conventional Heroku CI tests, and is incompatible with Fir.
Operationalizing Macaroons
Operationalizing Macaroons at Fly.io requires treating them as online-stateful bearer tokens whose nonces must be checked against database state, while keeping root secrets away from the primary API cluster. The team built tkdb, a roughly 5,000-line Go service backed by encrypted SQLite managed with LiteFS and Litestream, deployed on isolated hardware across the US, Europe, and Australia. Its HTTP/Noise interface supports verification and restricted signing, while FlyCast routing, retries, and client-side caching reduce the impact of unreliable global connectivity; verification caching exceeds 98%. Revocation uses blacklist state, and third-party caveats let services such as flyd obtain narrowly scoped secret-reading authority through tkdb rather than holding broad credentials. OpenTelemetry, standard metrics, and a retained OpenSearch audit trail provide visibility, while the post concludes that Macaroons’ internal infrastructure benefits outweigh limited user adoption.
Building Ramp's MCP server
Ramp built an open-source MCP server that exposes its developer API to LLMs through tools and a SQL interface, enabling natural-language access to business spend data. Using FastMCP in Python and Claude Desktop, the prototype could run analyses, generate visualizations, and issue cards on demand, but pagination struggled beyond a few hundred transactions because of miscalculations, context limits, input sizes, and token use. The team replaced bulk responses with an in-memory ETL that flattens API JSON into SQLite, then exposes load, transformation, and query tools; an OLAP-powered API was added for reporting workloads that caused timeouts. This let Claude analyze tens of thousands of spend events with aggregate and window functions while reducing token usage, although API latency, occasional reliability problems, tool-selection errors, and security risks remain; audit logs, OAuth scopes, and constrained tools provide mitigations, while write actions await a safety framework.
Simplifying JVM App Development with Heroku’s Buildpack Magic
Heroku’s Java buildpacks simplify JVM application deployment by detecting project languages and frameworks, fetching build tools, and configuring runtime settings automatically. They support Spring Boot, Quarkus, and Micronaut by inspecting Maven or Gradle build definitions, packaging applications, selecting framework-specific runner commands, and mapping service variables such as SPRING_DATASOURCE_URL, SPRING_REDIS_URL, DATABASE_URL, and JDBC_DATABASE_URL. In many cases, a Procfile is unnecessary because the buildpack can identify the executable JAR and provide a default web process, while Quarkus and Micronaut receive their respective runner JAR and port settings. Heroku also automatically attaches a lightweight JVM agent for runtime metrics, including memory usage and garbage collection, and offers similar buildpack support for Scala and Clojure through sbt and Leiningen.
Top topics
- Architecture834
- Performance816
- LLMs660
- Machine Learning622
- Open Source563
- AI Agents553
- AI470
- Developer Experience448
Weekly digest
The best engineering reads, once a week.