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 engineering challenges she encountered scaling Slack and GitHub. The discussion covers Slack’s WebSocket load testing and event floods, GitHub’s database queries and sharding constraints, and Lemaire’s emphasis on verifying AI-generated work on foundational systems.
The Pragmatic Engineer has published an interview with Maude Lemaire, a principal engineer, about the infrastructure and performance challenges she encountered at Slack and GitHub. The discussion describes how Slack prepared for a prospective customer with 500,000 users, why GitHub’s database access patterns constrained sharding, and how Lemaire approaches AI-generated code in foundational engineering work.
Lemaire spent nearly eight years at Slack, where she led the backend performance infrastructure team, before joining GitHub in 2024 to work on database scaling. The interview also covers her more recent performance work at Cursor, including efforts involving time to first token. It is presented as an episode of The Pragmatic Engineer, with listening and viewing options and a transcript referenced on the episode page.
One Slack example concerns an enterprise prospect with 500,000 users. Lemaire said a load test based on headless Chrome sessions would have cost about $150,000 per five-hour run, using the rates and setup described in the interview. She instead built Koi Pond, a tool that used lightweight Slack-like clients written in Go to open WebSocket connections. The source says this reduced the need to run a full browser for each simulated user; it does not provide a final benchmark or test result.
The conversation also explains two different sources of load at Slack: a thundering herd, in which an action prompts many users to generate events that must be distributed widely, and an event flood, in which one client receives a sudden volume of activity. At GitHub, Lemaire discussed how frequent database queries through the Rails application and Active Record could increase load, including a homepage that, according to the report, could trigger around 100 SQL queries across three database clusters. The source says scatter queries contributed to a historical limit of 16 database shards.
How Scale Changes Everyday Engineering
The examples show that scaling a popular product is not only about adding servers. Product behavior can multiply infrastructure work: a burst of reactions in a large Slack workspace can generate many distributed events, while a single user with numerous active channels can receive a concentrated stream over a WebSocket. Those patterns affect capacity planning and the experience of both large workspaces and highly active users.
The GitHub account highlights a different trade-off. An abstraction such as Active Record can make database access easier for application developers, but the interview argues that it can also obscure the volume and distribution of queries reaching underlying systems. For readers building or operating large software services, the discussion offers concrete examples of why application design, database architecture and load testing need to be considered together. These are Lemaire’s experiences as recounted in an interview, not a general audit of either company’s current infrastructure.
Products Worth Considering
Bose QuietComfort Wireless Noise Cancelling Headphones, Black
Bose SoundLink Flex Bluetooth Speaker (2nd Gen) – Portable Outdoor Speaker with Hi‑Fi Audio, Waterproof and Dustproof, USB‑C, Up to 12 Hours
Apple AirPods Pro 3 Wireless Earbuds with Active Noise Cancellation
As an affiliate, we earn on qualifying purchases.
Lemaire’s Work Across Three Platforms
The episode focuses on Lemaire’s experience at different stages of software growth. At Slack, she worked on backend performance and infrastructure as the company served larger enterprise customers. The interview revisits load testing and the difficulty of reproducing user connections at scale without the cost of running a full browser for every simulated client.
At GitHub, she joined in 2024, a period the source describes as Copilot gaining momentum. The discussion turns to the company’s large Ruby on Rails monolith and the database consequences of application patterns built on Active Record. It also includes a view of performance work at Cursor. The source names these roles and topics, but does not provide detailed timelines for the individual engineering changes discussed.
The episode connects those technical accounts with Lemaire’s broader view of performance. In one example from earlier in her career at Rent the Runway, she recalled a homepage that could take up to 10 seconds to fully load because of a high-resolution hero image. She said she chose to improve it even when she was told competition was not a reason to prioritize the work. The point, as she framed it, was that teams can improve the user experience by competing with their own prior performance.
“The best competition is competition with yourself, knowing that you can do better, knowing that you can drive a better experience.”
— Maude Lemaire, discussing performance at Rent the Runway, as quoted by The Pragmatic Engineer
Limits of the Reported Examples
The source is an interview summary, not a company engineering postmortem or a current operational report. It does not give the date of publication, the results of the 500,000-connection load test, or whether the described Slack and GitHub limits and database patterns remain in place. The 23-emoji limit and 16-shard ceiling are presented as examples from the discussion, without a full account of when they applied or whether later changes altered them.
The report also does not quantify the performance improvements Lemaire achieved at Slack, GitHub or Cursor, or provide independent measurements for the systems described. The account of Active Record and query volume should be understood as a lesson drawn from Lemaire’s experience, rather than a complete assessment of GitHub’s database architecture. No transcript excerpts beyond the wording reproduced in the source material are available here.
Where to Hear the Full Interview
The next step for readers who want more detail is to consult the full episode and transcript referenced by The Pragmatic Engineer. The source says the episode is available on YouTube, Apple and Spotify, with timestamps listed on its page. Those materials may provide additional detail on the sequence of events and Lemaire’s explanations.
The source does not announce a new product, policy change or follow-up milestone at Slack or GitHub. Any claims about current limits, later infrastructure changes or results beyond the examples in the interview would require further confirmation from the companies or additional reporting.
Key Questions
What is the news?
The Pragmatic Engineer published an interview with Maude Lemaire about scaling Slack and GitHub, drawing on her infrastructure and performance work at both companies.
How did Lemaire approach Slack’s 500,000-user load test?
Rather than run a full headless Chrome instance for every simulated user, she built Koi Pond, which used lightweight clients written in Go to establish WebSocket connections. The source estimates the browser-based approach would have cost about $150,000 for a five-hour run, but does not report the final test results.
What database problem did the interview describe at GitHub?
The interview describes how Active Record queries could create substantial database load, including a homepage request that could trigger around 100 SQL queries across three clusters. It also says scatter queries were a reason GitHub could not add more than 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 platform work. It does not claim that she rejects AI tools or describe a formal company-wide policy.
Where can readers find the episode?
The source lists YouTube, Apple and Spotify as listening or viewing options and references an episode transcript and timestamps on The Pragmatic Engineer’s page.
Source: newsletter.pragmaticengineer.com
