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 Slack and GitHub, drawing on her nearly eight years at Slack and later work on GitHub database scaling. The discussion covers Slack’s approach to WebSocket load testing, database and sharding constraints at GitHub, and Lemaire’s practice of checking AI-generated work herself.
The Pragmatic Engineer has published an interview with engineer and author Maude Lemaire about scaling Slack and GitHub, including how Slack tested a potential influx of 500,000 users and how GitHub’s database design limited its ability to add shards. The account offers a practitioner’s perspective on the performance trade-offs behind widely used software products, rather than a new company announcement or independent system audit.
Lemaire spent nearly eight years at Slack, where she led the backend performance infrastructure team, according to The Pragmatic Engineer. She later joined GitHub to work on database scaling challenges. The interview also discusses her more recent work on performance at Cursor, including time to first token. Lemaire is the author of Refactoring at Scale: Regaining Control of Your Codebase.
One Slack example concerned a prospective customer with 500,000 users. Lemaire initially considered running a test with headless Chrome, with each browser instance maintaining a Slack session. The report says that approach would have cost about $0.37 per instance for a five-hour session, or roughly $150,000 for a full run. Instead, she built Koi Pond, a tool that used slimmed-down Slack clients written in Go to establish WebSocket connections. The source describes the tool and estimated cost; it does not provide test results or a later customer outcome.
The interview also describes Slack’s concern about event volume. The report says the service caps custom emoji reactions at 23 to limit the fan-out burden when many users react to a message. It distinguishes this from an “event flood,” in which a single client receives a surge of messages and other events across busy channels. At GitHub, Lemaire discusses a different scaling problem: database queries made through Rails’ Active Record abstraction could create substantial load, while scatter queries across shards made adding database shards harder.
The examples show why adding users or capacity is not always a matter of buying more servers. At Slack, a popular message and its reactions could generate large numbers of network fan-outs, while a single heavily connected user could be overwhelmed by events. The reported 23-emoji limit is a product constraint intended to manage that infrastructure effect; it also illustrates how engineering decisions can shape what users are allowed to do.
GitHub’s database examples point to a separate tension: abstractions that make application development easier can obscure the work performed beneath them. The interview says homepage requests could trigger around 100 SQL queries across three database clusters, and that scatter queries without a sharding key became slower as they had to reach more shards. These details help explain why scaling requires attention to application behavior and query patterns, not only database capacity. They are examples from Lemaire’s account, not a claim that every Rails application behaves the same way.
For engineers and technology leaders, the discussion is relevant because it connects user-facing performance to choices about testing, data access and product limits. It also addresses the growing use of AI in engineering: Lemaire says she checks generated output carefully for foundational work, where errors could affect the reliability of later systems.
Popular right now
Bose QuietComfort Wireless Noise-Cancelling Headphones, Cypress Green
Dyson Car+Boat Cordless Handheld Vacuum
Dyson V15 Detect Cordless Vacuum
As an affiliate, we earn on qualifying purchases.
From Slack Infrastructure to GitHub Data
The interview is part of The Pragmatic Engineer’s discussion of scaling large software products. It draws on Lemaire’s experience across several engineering environments: she worked on performance infrastructure at Slack, joined GitHub in 2024 as Copilot was gaining traction, and later worked on performance at Cursor. The report does not present the interview as a formal retrospective published by Slack or GitHub.
At Slack, the account focuses on handling enterprise growth and developing load tests that could model many connected clients without the cost of full browser sessions. The Koi Pond approach simulated WebSocket connections with lighter clients. At GitHub, the focus shifts to the company’s large Ruby on Rails monolith, Active Record database access and the limits imposed by scatter queries. Together, the cases show different bottlenecks: connection and event volume in one system, and query behavior and sharding in another.
The source also recounts Lemaire’s earlier work at Rent the Runway, where she chose to improve a slow-loading homepage despite being told competition was not a concern. She describes performance as a goal in its own right, not just a response to rivals. This is her stated lesson from that experience, rather than a measured finding about the business impact of the work.
“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 by The Pragmatic Engineer
Limits of the Interview Account
The source is an interview summary and does not include independent measurements, Slack or GitHub responses, or a complete technical review of the systems described. It does not state whether the 500,000-user load test was completed, what results it produced, or whether the prospective customer ultimately signed up. The estimated $150,000 figure describes the proposed headless Chrome approach, not spending on the Koi Pond test.
The report gives examples of Slack’s emoji limit and GitHub’s database behavior but does not specify when those systems or constraints were changed, whether they remain in place today, or how the companies’ current architectures differ. It also does not quantify the performance improvements at Cursor or provide benchmark data for Lemaire’s work. Those details should not be inferred from the interview summary.
Further Detail Depends on the Episode
The Pragmatic Engineer says the full interview is available to watch or listen to on YouTube, Apple and Spotify, with a transcript and episode timestamps on its page. Those materials may provide more detail about Lemaire’s examples and the decisions behind them. The source does not announce a follow-up, a new Slack or GitHub product change, or a scheduled technical release tied to the interview.
For now, the development is the publication of Lemaire’s account. Any conclusions about present-day Slack limits, GitHub shard counts, or subsequent performance work would require newer company information or additional reporting.
Key Questions
What is the news?
The Pragmatic Engineer published an interview with Maude Lemaire about scaling and performance work at Slack, GitHub and Cursor.
What was Slack’s Koi Pond tool used for?
The report says Koi Pond used lightweight clients written in Go to establish WebSocket connections for a load test involving a prospective customer with 500,000 users. It was presented as a less costly alternative to running a headless Chrome instance for every simulated user.
What database issue did Lemaire describe at GitHub?
The interview discusses how Active Record queries could create substantial database activity and how scatter queries, which lack a sharding key, had to run across shards. The report says this made adding shards harder, but it does not establish GitHub’s current shard limit or architecture.
Does the report say the Slack load test succeeded?
No result is provided in the supplied report. It describes the proposed test and the Koi Pond tool, but does not say whether the test ran, what it found, or whether the customer signed up.
How does Lemaire use AI in engineering?
The interview says she uses AI tools but personally checks their output closely for foundational work. The source does not provide a detailed list of tools, workflows or measured productivity effects.
Source: newsletter.pragmaticengineer.com
