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 work at both companies and, more recently, Cursor. She describes Slack’s approach to load testing and event surges, GitHub’s database and Rails challenges, and why she personally verifies AI output for foundational engineering work.
The Pragmatic Engineer has published an interview with Maude Lemaire about scaling Slack and GitHub, including how Slack prepared for a customer with 500,000 users and how GitHub’s database architecture constrained its ability to add shards. Lemaire draws on nearly eight years at Slack, subsequent work on GitHub database scaling, and more recent performance work at Cursor.
At Slack, Lemaire led the backend performance infrastructure team. In the interview, she discusses the demands of enterprise growth, the service’s approach to load testing, and how bursts of activity can place unusual strain on its infrastructure. One example is a “thundering herd”: a popular message in a large channel can prompt many reactions, each of which may need to be distributed to every member. The report says Slack limits custom emojis to 23 to reduce the potential load from this pattern.
The interview also describes a planned test for a prospective customer with 500,000 users. Lemaire initially considered using headless Chrome sessions to simulate Slack clients. According to the report, that approach would have cost about $150,000 per five-hour run. Instead, she built Koi Pond, a tool that used slimmed-down clients written in Go to establish WebSocket connections. The account presents this as a way to test connection scale without running a full browser for every simulated user.
At GitHub, where she joined in 2024, Lemaire worked on database scaling during a period when Copilot was growing. The interview describes GitHub’s large Ruby on Rails monolith and the database load associated with application patterns using Active Record. The report says a homepage reload could trigger roughly 100 SQL queries across three database clusters. Many queries were scatter queries—queries without a sharding key that had to reach across shards—which made adding shards more difficult.
How Scale Shapes Product Reliability
The examples show that scaling is not simply a matter of adding servers. Product behavior, application abstractions, and the shape of database queries can all determine whether a system handles growth efficiently. Slack’s emoji example links a small user-facing limit to the potential cost of distributing activity across a very large workspace.
The load-test account also illustrates a practical trade-off for infrastructure teams: a realistic test must represent the load being studied, but the method used to generate that load can itself be expensive. Koi Pond was designed to create large numbers of WebSocket connections with lighter clients rather than full browser sessions. For readers responsible for large services, the interview offers concrete examples of how engineering teams identify and work around those constraints.
Lemaire’s GitHub account highlights a different risk: abstractions can make database access easier for developers while obscuring the cumulative work that requests create. When queries do not target a specific shard, adding more shards may not resolve the bottleneck and can make scatter queries slower. These are interview accounts, not a full technical audit of either company’s current systems.
Products Worth Considering
LG UltraGear 32GS60QC-B 32-inch Curved QHD Gaming Monitor (180Hz, 1ms, 1000R, AMD FreeSync, HDR10)
LG UltraGear 34GX90SA-W 34-inch WQHD Curved OLED Gaming Monitor
LG UltraGear 32GX850A-B 32-inch 4K UHD Glossy OLED Gaming Monitor
As an affiliate, we earn on qualifying purchases.
Lemaire’s Work Across Three Companies
Lemaire is a principal engineer and the author of Refactoring at Scale: Regaining Control of Your Codebase. The Pragmatic Engineer reports that she spent nearly eight years at Slack before joining GitHub to address database scaling challenges. She later worked on performance at Cursor, including time to first token, the delay before a system begins producing a response.
The interview connects these roles through a recurring concern: how software behaves as usage and system complexity grow. At Slack, the discussion centers on WebSocket connections, enterprise customers, and sudden volumes of events. At GitHub, it focuses on a Rails monolith, database queries, and sharding. The source also discusses Lemaire’s use of AI tools, but emphasizes that she keeps judgment and decision-making in her own hands.
“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 Interview Account
The supplied report does not give a publication date, the outcome of the prospective 500,000-user customer test, or whether that customer ultimately joined Slack. It also does not provide current measurements for Slack’s event handling or GitHub’s database architecture, so the examples should not be read as descriptions of either service’s present-day limits.
The source says GitHub could not add more than 16 database shards because of scatter-query problems, but it does not specify when that limit applied or describe later architectural changes. The interview’s examples explain the challenges Lemaire encountered; they do not establish that the same constraints remain in place.
Where the Interview Points Next
The immediate next step for readers is the full interview: The Pragmatic Engineer says the episode is available on YouTube, Apple, and Spotify, with a transcript and episode timestamps on its page. The source does not announce a new product, policy change, or engineering milestone from Slack or GitHub.
Further reporting would be needed to establish what happened after the load test, how GitHub’s sharding constraints changed over time, and how Lemaire’s performance work at Cursor developed. For now, the interview serves as a retrospective on engineering decisions across three companies rather than a report of a newly announced system change.
Key Questions
What is the news about Maude Lemaire?
The Pragmatic Engineer published an interview with Lemaire about scaling Slack and GitHub, based on her engineering work at both companies and later performance work at Cursor.
How did Slack test 500,000 user connections?
According to the report, Lemaire built Koi Pond, a tool using lightweight Go clients to establish WebSocket connections. This avoided the much higher projected cost of using a headless Chrome instance for every simulated session.
Why did GitHub’s database shards create a challenge?
The interview says many queries lacked a sharding key and therefore had to run across multiple shards. These scatter queries became slower as shard counts increased, limiting how far that approach could scale, according to the report.
What does Lemaire say about using AI for engineering?
The report says she uses AI tools but personally verifies their output for foundational work, keeping judgment and engineering decisions under her own control.
Source: newsletter.pragmaticengineer.com
