TL;DR
Get the latest gadgets delivered free with Prime
- Fast, free delivery on millions of items
- Prime Video, Amazon Music and more included
- Member-only deals all year
The Pragmatic Engineer published an interview with Maude Lemaire about scaling infrastructure at Slack and GitHub, drawing on her experience at both companies. The discussion covers Slack’s WebSocket load testing and event-flood problems, GitHub’s database query patterns, and Lemaire’s approach to checking AI-generated work.
The Pragmatic Engineer has published an interview with Maude Lemaire, a principal engineer whose work has included scaling Slack’s backend and addressing database challenges at GitHub. The discussion lays out specific engineering problems at both services, including how Slack prepared for a customer with 500,000 users and why GitHub’s query patterns constrained its database sharding.
Lemaire spent nearly eight years at Slack, where she led the backend performance infrastructure team, before joining GitHub in 2024. According to The Pragmatic Engineer’s account of the interview, her Slack work included developing a way to test large numbers of WebSocket connections without launching a full browser for every simulated user. She built Koi Pond, a tool using slimmed-down Slack clients written in Go, after estimating that a headless-Chrome test for 500,000 connections would cost about $150,000 per five-hour run.
The interview also describes two types of load pressure Slack had to manage. The report says Slack limits custom emoji reactions to 23 to reduce the fan-out of events across large channels. It also discusses “event floods,” in which a single client—such as an IT worker connected to many active channels—can receive a sudden volume of messages and related events over its WebSocket connection. These examples show that scaling is not only about total users: the way activity spreads across channels and individual clients can also affect service performance.
At GitHub, Lemaire encountered database costs associated with the company’s Ruby on Rails monolith and its use of Active Record. The report says a homepage load could trigger around 100 SQL queries across three database clusters. It also describes scatter queries—queries without a sharding key that must reach multiple database shards—as a reason GitHub could not add more than 16 shards at the time discussed. The interview further touches on Lemaire’s later performance work at Cursor, including time to first token, and her practice of personally checking AI-generated output for foundational engineering work.
How Load Shapes Product Design
The examples make infrastructure trade-offs concrete for teams operating products with large customer bases. A design choice that is easy for an application developer—such as retrieving data through a database abstraction—can produce substantial work across database clusters when repeated at scale. At Slack, meanwhile, a burst of activity in a large channel can multiply into many network events, while a single heavily connected user can face a separate overload problem.
The interview is also relevant to teams planning enterprise deployments. Slack’s reported load test was tied to a prospective 500,000-user customer, illustrating why capacity needs may need to be tested before a major customer arrives. Lemaire’s account of using lightweight clients rather than browser instances offers an example of how test design itself can affect the cost and practicality of validating capacity. These are lessons from one engineer’s experience, not evidence that the same limits or methods apply unchanged to every system.
Products Worth Considering
LG UltraGear 32GX850A-B 32-inch 4K UHD Glossy OLED Gaming Monitor
LG UltraGear 34GX90SA-W 34-inch WQHD Curved OLED Gaming Monitor
DJI Mic 2 Wireless Microphone System (2 Transmitters, Receiver, Charging Case)
As an affiliate, we earn on qualifying purchases.
Lemaire’s Path Through Large Systems
The interview draws on Lemaire’s work across several software organizations. Before Slack, she worked at Rent the Runway, where she recalled a homepage that could take as long as 10 seconds to load in 2015 because of a high-resolution hero image. The source says she chose to work on improving the page even though she had been told competition was not a pressing concern. She described performance as a matter of improving the experience, rather than responding only to rivals.
After nearly eight years at Slack, Lemaire joined GitHub in 2024, as Copilot was gaining traction, according to the report. Her GitHub work involved database scaling in a large Rails codebase. The Pragmatic Engineer presents the conversation as a discussion of lessons from these roles, alongside her book, Refactoring at Scale: Regaining Control of Your Codebase. It also notes that she later worked on performance at Cursor. The source is an interview and episode summary; it does not present a new independent benchmark or company-wide performance study.
“The best competition is competition with yourself, knowing that you can do better, knowing that you can drive a better experience.”
— Maude Lemaire, as quoted in The Pragmatic Engineer
Limits of the Reported Examples
The source provides an interview and selected examples, not a full technical account of Slack’s or GitHub’s current infrastructure. It does not establish whether Slack’s 23-emoji limit, GitHub’s 16-shard constraint, or the described query patterns remain in place today. The reported $150,000 figure is an estimate for a particular proposed five-hour load test, not a general cost for testing WebSocket capacity.
The report also does not give detailed measurements of how Koi Pond performed in production tests, what changes followed the GitHub database findings, or the scale of Lemaire’s later Cursor work. The account of AI use describes her personal practice; it should not be read as a formal policy for her employers or as an evaluation of a particular model.
Where to Find the Full Interview
The Pragmatic Engineer’s source page directs readers to the interview on YouTube, Apple, and Spotify, with a transcript and episode timestamps. Those materials are the next source for further detail on Lemaire’s explanations and the sequence of events behind the Slack and GitHub examples. The report does not announce a new product, policy change, or upcoming infrastructure milestone at either company.
Key Questions
What is the news?
The Pragmatic Engineer published an interview with Maude Lemaire about her experience scaling Slack and working on GitHub’s database challenges, as well as later performance work at Cursor.
How did Slack test for a 500,000-user customer?
According to the report, Lemaire built Koi Pond, which uses slimmed-down clients written in Go to create WebSocket connections. This avoided the estimated cost of using a separate headless Chrome instance for every simulated session.
Why did GitHub’s database queries make adding shards difficult?
The report says many queries lacked a sharding key and therefore had to run across multiple shards. These scatter queries became slower as the number of shards grew, contributing to a reported limit of 16 shards at the time discussed.
What does Lemaire say about using AI for engineering?
The source says she uses AI in her work but personally verifies its output for foundational tasks. The interview frames this as her approach to protecting the reliability of underlying systems, not as a company-wide rule.
Source: newsletter.pragmaticengineer.com
