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 at both companies. The discussion covers Slack’s WebSocket load testing and event-flood safeguards, GitHub’s database and sharding constraints, and Lemaire’s approach to using AI tools.
The Pragmatic Engineer has published an interview with Maude Lemaire, a principal engineer whose past work includes scaling Slack’s backend and addressing database challenges at GitHub. The discussion details how product design, load testing and database abstractions can shape the capacity and reliability of large software services, and how Lemaire checks AI-generated work on foundational engineering tasks.
At Slack, Lemaire spent nearly eight years and led the backend performance infrastructure team, according to The Pragmatic Engineer. One example discussed in the interview is Slack’s limit of 23 custom emojis. The report says the cap helps reduce the risk of a thundering herd: when a popular message prompts many users to react, each custom emoji may need to be sent to users across a large channel, multiplying network traffic.
The interview also describes a load test planned for a prospective Slack customer with 500,000 users. Lemaire initially considered using headless Chrome to simulate individual sessions. The report estimates that approach would cost $0.37 per instance for a five-hour session, or about $150,000 for the test. Instead, she built Koi Pond, a tool using lightweight Go clients called Koi to open WebSocket connections without running a full browser for each simulated user.
At GitHub, where she joined in 2024, Lemaire worked on database scaling as the company’s Copilot product was growing, the report says. The interview describes a Rails monolith in which homepage requests could trigger around 100 SQL queries across three database clusters. Many queries without a sharding key had to run across multiple shards; the source says this scatter-query pattern constrained GitHub’s ability to add more than 16 database shards. The interview also covers Lemaire’s more recent performance work at Cursor, including time to first token.
Scaling Without Overloading Slack
The examples show that scaling is not only a matter of adding servers. A feature that appears small to an individual user, such as a custom emoji reaction, can create substantial work when its effects spread across a large channel. Slack’s reported emoji cap and the separate problem of event floods illustrate how fan-out and client-side message volume can become operational concerns as usage grows.
The load-test example points to a practical trade-off: realistic browser simulations can be expensive at large scale, while a purpose-built client can test a particular infrastructure limit more economically. At GitHub, the account highlights a different constraint: a database abstraction can make application development easier while obscuring how many queries a routine page load generates. For readers building or operating software platforms, the interview offers specific examples of how product behavior, tooling and data access patterns affect capacity.
These are accounts of Lemaire’s work and the systems described in the interview, not a published benchmark of either company’s current performance. They are useful as engineering case studies, but the source does not provide independent measurements or a full account of present-day architecture.
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
Samsung Galaxy Tab A11 Wi‑Fi (International Version), 8.7, 64GB + 4GB, Gray
As an affiliate, we earn on qualifying purchases.
From Slack Infrastructure to GitHub Databases
Lemaire is the author of Refactoring at Scale: Regaining Control of Your Codebase. According to the source, after her time at Slack she joined GitHub in 2024, when Copilot was gaining traction, and later worked on performance at Cursor. The interview focuses on lessons from those roles rather than announcing a new product, company policy or engineering release.
The Slack examples distinguish two kinds of load. A thundering herd occurs when an action triggers a surge of work across many users or systems. An event flood, as described in the interview, happens when one client receives a sudden burst of events through its WebSocket connection, such as an employee active in many busy channels. At GitHub, the reported issue was database work spread across shards when queries lacked the key needed to route them to a particular shard.
The source also recounts an earlier experience at Rent the Runway in 2015: Lemaire said the homepage could take up to 10 seconds to load because of a high-resolution hero image. She described working on improving it despite being told competition was not a concern. That story frames a broader view expressed in the interview: performance can matter as an experience goal even without immediate competitive pressure.
“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
Details the Interview Does Not Establish
The source is an interview summary, not a technical postmortem or a current architecture disclosure. It does not specify when Slack introduced the 23-emoji limit, whether that cap remains unchanged, or how the described safeguards compare with Slack’s current systems. The load-test estimate is presented for the proposed browser-based method and a five-hour session; the source does not provide a complete breakdown of the test’s assumptions or the final test results.
The GitHub figures—about 100 SQL queries across three clusters and a 16-shard ceiling—are reported as historical examples. The material does not date those conditions precisely or say whether they still apply after subsequent engineering changes. It also does not give detailed outcomes or metrics for Lemaire’s work at Cursor. The interview’s discussion of AI describes her personal verification practice, not a company-wide policy or a measured assessment of AI tools.
Where Readers Can Hear More
The Pragmatic Engineer says the full conversation is available as a podcast and video on YouTube, Apple and Spotify, with a transcript and episode timestamps on its page. The supplied report does not announce a follow-up release, a new engineering project from Lemaire, or further company disclosures. Readers seeking detail beyond the summary will need to consult the full episode and transcript; any claims about current Slack or GitHub infrastructure would require newer confirmation from the companies or their engineers.
Key Questions
What is the news development?
The Pragmatic Engineer published an interview with Maude Lemaire about her engineering work at Slack and GitHub, including performance, load testing and database scaling.
How did Lemaire test Slack at the scale of 500,000 users?
According to the report, she built Koi Pond, which uses lightweight Go clients called Koi to create WebSocket connections. It was an alternative to simulating every user with a headless Chrome browser, which the source estimated would cost about $150,000 for a five-hour run.
Why did GitHub’s database queries limit sharding?
The interview describes queries without a sharding key as scatter queries, because they must run across shards rather than being routed to one. The source says this pattern constrained GitHub’s ability to add more than 16 shards at the time described.
What does Lemaire say about using AI at work?
The report says Lemaire uses AI tools but personally verifies their output, particularly for foundational platform work. It does not present this as a formal policy at Slack, GitHub or Cursor.
Source: newsletter.pragmaticengineer.com
