Scaling Slack And GitHub With Maude Lemaire
AIThis post was created with the assistance of artificial intelligence (AI).

TL;DR

Buying for a business?Offer from Amazon

Get business pricing on monitors, keyboards and dev gear

  • Business-only prices and quantity discounts
  • Tax-exempt purchasing
  • Multiple users, one account, clear invoices
As an affiliate, we earn on qualifying purchases.

The Pragmatic Engineer published an interview with Maude Lemaire about scaling infrastructure at Slack and GitHub, drawing on her work at both companies. The discussion covers Slack’s approach to sudden traffic and event surges, GitHub’s database and sharding constraints, and Lemaire’s emphasis on checking AI-generated work on foundational systems.

The Pragmatic Engineer has published an interview with principal engineer Maude Lemaire about scaling Slack and GitHub, including how Slack prepared for a customer with 500,000 users and how database query patterns constrained GitHub’s sharding. The account offers practitioners concrete examples of how product features and convenient software abstractions can create infrastructure demands as services grow.

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, according to The Pragmatic Engineer. She later worked on performance at Cursor, including time to first token. The interview ranges from load testing and event handling to her use of AI tools in engineering work.

One example concerns a prospective Slack customer with 500,000 users. Lemaire said a proposed test using headless Chrome would have cost about $0.37 per instance for a five-hour session, or roughly $150,000 for a run at the planned scale. She instead built Koi Pond, a tool that used lightweight Slack-like clients written in Go to establish WebSocket connections. The source describes the alternative as a way to test connection loads without running a full browser session for every simulated user.

The interview also describes two types of load challenges at Slack. A burst of custom emoji reactions can multiply the work of distributing events across a large channel; the article says Slack caps custom emojis at 23 to limit that risk. Separately, a single user connected to many active channels may receive a flood of events over a WebSocket connection. At GitHub, Lemaire discussed how database-backed page requests and scatter queries—queries that must reach every shard because they lack a sharding key—made adding shards more difficult.

At a glance
reportWhen: Published on The Pragmatic Engineer; th…
The developmentThe Pragmatic Engineer published an interview with Maude Lemaire about engineering challenges she encountered scaling Slack and GitHub.

How Product Choices Shape Infrastructure

The examples show that scaling is not only a matter of adding servers. A feature that appears small to an individual user, such as an emoji reaction, can produce large amounts of distributed work when repeated across a large channel. Likewise, an application’s data-access patterns can turn a routine page load into substantial database activity.

For engineering teams, Lemaire’s account highlights a trade-off between developer convenience and operational visibility. Abstractions can make it easier to build features, but they may obscure the number and reach of database queries. The Slack load-test example also illustrates why realistic tests matter before a major customer brings a large number of connections or users onto a service.

The interview is a practitioner’s account rather than a formal performance study. Its value is in the specific engineering cases and decisions it describes, not in establishing universal limits for other systems.

Products Worth Considering

Fitbit Sense 2 Health and Fitness Smartwatch, Shadow Grey/Graphite

Fitbit Sense 2 Health and Fitness Smartwatch, Shadow Grey/Graphite

As an affiliate, we earn on qualifying purchases.

Lemaire’s Path Through Scaling Work

The discussion draws on Lemaire’s work across several software companies. At Slack she focused on backend performance infrastructure during a period of enterprise growth. She joined GitHub in 2024, as GitHub Copilot was growing, and encountered the challenges of working with a large Ruby on Rails codebase, the source says. The interview also touches on her later performance work at Cursor.

One GitHub example in the report concerns the company’s Rails monolith and its use of Active Record, a database abstraction layer. The article says that, in the period discussed, a homepage load could trigger about 100 SQL queries across three database clusters. Many queries were scatter queries, which need to be run across all shards. According to the interview account, this pattern limited GitHub’s ability to add more than 16 database shards because increasing the number of shards could make those queries slower.

The source also frames Lemaire’s approach to performance as a matter of engineering judgment, not only competition. It recounts her earlier work improving Rent the Runway’s page load after a page had taken as long as 10 seconds to load fully. She argued that improving a user experience could be worthwhile even without a direct competitor prompting 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 in The Pragmatic Engineer

Limits of the Interview Account

The source is an interview summary, not a complete technical specification or an independently audited account. It does not provide dates for the Slack emoji limit, GitHub’s 16-shard constraint, or the exact timeframe in which the homepage query pattern applied. Those figures should be read as examples from the systems and periods discussed, not as descriptions of current configurations.

The report does not state whether Slack or GitHub still use the specific designs described, or how their architectures may have changed since Lemaire’s work. It also does not provide a full cost comparison for Koi Pond against the headless-browser test, beyond the stated projected cost for the original approach. The interview’s references to LLM verification describe Lemaire’s practice, not a measured assessment of AI tools’ accuracy.

Further Details in the Episode

The source directs readers to the full Pragmatic Engineer episode, available on YouTube, Apple and Spotify, and says a transcript and episode timestamps are available on the episode page. Those materials are the next place to check for the full conversation and additional technical detail. The source does not announce a follow-up investigation, new product release or scheduled milestone related to the interview.

Key Questions

What is the news?

The Pragmatic Engineer published an interview with Maude Lemaire about scaling infrastructure at Slack and GitHub, based on her experience at both companies.

What was Slack’s Koi Pond tool for?

Lemaire built Koi Pond to simulate Slack WebSocket connections with lightweight clients written in Go. The aim was to test a prospective 500,000-user customer scenario without running a full headless Chrome session for each simulated user.

Why did GitHub’s database queries limit sharding?

The interview describes scatter queries that lacked a sharding key and therefore had to run across every shard. The report says many such queries made through Active Record contributed to a limit of 16 database shards in the system being discussed.

What does Lemaire say about using AI for engineering?

The report says Lemaire uses AI tools but personally verifies their output, particularly for foundational platform work. It presents this as her working approach, not as a general claim about AI reliability.

Source: newsletter.pragmaticengineer.com

You May Also Like

Linux From Scratch

Search interest in Linux From Scratch spikes, reflecting growing curiosity in custom Linux builds. Details remain unconfirmed, but trend signals increased engagement.

Microsoft Killed FoxPro In 2007. Anyway, Here’s FoxPro Revived

After Microsoft ended support for FoxPro in 2007, a new effort has emerged to revive the legacy database system, surprising many industry observers.

Single Log Line Is 49KB+ (Ext4) / 110KB+ (Btrfs) Of Systemd-journald Disk Writes

New findings reveal systemd-journald writes produce log entries over 49KB on ext4 and over 110KB on Btrfs, raising concerns about storage efficiency.

Show HN: Woxi – Open-source Mathematica / Wolfram Language Reimplementation

Woxi is an open-source interpreter for Wolfram Language, written in Rust, offering a Mathematica-like GUI and multiple interfaces, now available on Show HN.