TL;DR
Get business pricing on monitors, keyboards and dev gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
The Pragmatic Engineer published an interview with Maude Lemaire about scaling infrastructure at Slack and GitHub, drawing on her experience as a principal engineer. She discusses Slack’s approach to large WebSocket loads, GitHub’s database and sharding constraints, and why she verifies AI-generated work on foundational systems.
The Pragmatic Engineer has published an interview with Maude Lemaire about scaling Slack and GitHub, two large software platforms with distinct infrastructure challenges. Lemaire, a principal engineer who spent nearly eight years at Slack before joining GitHub in 2024, describes how Slack tested for hundreds of thousands of connected users and how GitHub’s database architecture constrained its ability to add shards.
At Slack, Lemaire led the backend performance infrastructure team, according to the interview. One challenge arose when a prospective customer with 500,000 users was preparing to sign up. To test whether Slack could handle that level of use, she initially considered running headless Chrome sessions, but the source says that approach would have cost $0.37 per instance for a five-hour session. At that rate, the test was estimated to cost about $150,000 per run.
Instead, Lemaire built Koi Pond, a load-testing tool that used slimmed-down Slack clients written in Go to establish WebSocket connections. The account illustrates a practical trade-off: simulating a large number of connections did not require running a full browser for every user. The interview also discusses event floods, in which a client receives a surge of activity across busy channels, and Slack’s reported limit of 23 custom emojis as a way to reduce the potential fan-out load from reactions.
At GitHub, Lemaire worked on database scaling after joining in 2024, when Copilot was gaining traction, the report says. GitHub’s Rails application used Active Record, and the interview describes homepage requests that could generate roughly 100 SQL queries across three database clusters. The report says many queries lacked a sharding key and had to run across multiple shards. These scatter queries helped limit GitHub to 16 database shards at the time described.
Testing Slack at Half a Million Connections
The examples show how scaling problems can emerge from ordinary product behavior, not only from major outages or unusually complex features. At Slack, a large customer’s user count meant the team needed to test many simultaneous connections. A simplified client made that test less costly than simulating every user with a full browser, while event floods showed how one particularly active user’s client could be strained by activity arriving over a WebSocket.
At GitHub, the issue described was less about connection volume and more about the interaction between application abstractions and database design. Active Record made it easier for application code to retrieve data, but the interview says developers could miss the resulting database workload. Queries that could not be routed to a particular shard had to be sent more broadly, making additional shards less useful and potentially slower for those requests.
For readers who build or operate software, the report offers concrete examples of infrastructure trade-offs: performance testing needs to reflect the real shape of traffic, and convenient application-level tools can conceal system-wide costs. Lemaire also discusses her use of AI tools, while emphasizing that she personally checks their output when working on foundational systems.
Popular right now
Dreame L40 Ultra Gen 2 Robot Vacuum and Mop with 25,000 Pa Suction
Ninja CM401 Specialty Coffee Maker with 10-Cup Carafe and Fold-Away Frother
KitchenAid 5.5-Qt Bowl-Lift Stand Mixer, Porcelain White (KSM55SXXX)
As an affiliate, we earn on qualifying purchases.
From Slack Infrastructure to GitHub Databases
Lemaire’s career provides the frame for the discussion. Before Slack, she worked at Rent the Runway, where she recalled that the homepage could take up to 10 seconds to load in 2015 because of a high-resolution hero image. The interview says she worked on improving the experience in her free time, despite being told that competition was not a reason to prioritize the issue. She describes performance as a goal in its own right, rather than only a response to competitors.
She then spent nearly eight years at Slack, including leading backend performance infrastructure, before joining GitHub in 2024 to work on database scaling. The interview also notes that she later worked on performance at Cursor, including time to first token. Lemaire is the author of Refactoring at Scale: Regaining Control of Your Codebase. The published discussion is presented as a podcast episode, with video and audio options and a transcript, according to The Pragmatic Engineer.
“The best competition is competition with yourself, knowing that you can do better, knowing that you can drive a better experience.”
— Maude Lemaire, speaking about improving Rent the Runway’s performance
Limits of the Reported Engineering Examples
The source is an interview summary, not a technical incident report or a current architecture document. It does not give the date of the 500,000-user load test, say whether the prospective customer ultimately signed up, or provide the test results. The $150,000 figure is an estimated cost for the proposed headless-browser approach, not a reported amount spent.
The account also does not establish whether Slack’s 23-emoji limit or GitHub’s 16-shard ceiling remain in place today. It gives no current shard count, performance measurements, or details on changes made after Lemaire’s work. The examples should be read as descriptions of challenges she discussed, rather than a complete or up-to-date inventory of either company’s infrastructure.
The source says Lemaire uses AI in her work and personally verifies output on foundational tasks, but it does not identify specific models, quantify productivity effects, or describe a formal review process. Those details remain unreported.
Episode Transcript and Further Details
The interview is available through the listening and viewing platforms listed by The Pragmatic Engineer, which also provides an episode transcript and timestamps. Readers seeking more detail can consult those materials for Lemaire’s full explanations of Slack’s load-testing approach, GitHub’s query patterns and her use of AI. The source does not announce a follow-up episode, a new engineering release, or a deadline for further developments.
Key Questions
What is the news about Maude Lemaire?
The Pragmatic Engineer published an interview in which Lemaire discusses engineering challenges she encountered scaling Slack and GitHub, along with her approach to AI-assisted work.
How did Slack test for 500,000 users?
Lemaire built Koi Pond, a tool that used slimmed-down clients written in Go to open WebSocket connections. The approach avoided the estimated cost of running a headless Chrome session for every simulated user.
Why did GitHub’s shard count face a limit?
The interview says many database queries lacked a sharding key and therefore had to run across shards. Those scatter queries could become slower as the number of shards increased; the source says this constrained GitHub to 16 shards at the time being discussed.
What does Lemaire say about using AI?
The report says she uses AI tools but personally verifies their output, especially for foundational engineering work. It does not name particular models or report measured productivity results.
Source: newsletter.pragmaticengineer.com
