Library / Case Studies
Scaling Slack - Bing Wei, Software Engineer (Infrastructure) at Slack
Bing Wei examines the limitations that Slack's backend ran into and how they overcame them to scale from supporting small teams to serving large organizations of hundreds and thousands of users. She tells stories about the edge cache service, real-time messaging system and how they evolved for major product efforts…
By Slack engineers · Slack · Added 2026-10-12
All content belongs to Slack engineers / Slack. We only link to it and give credit. Report a problem
Learn this case study
About 37 min left. Your work is saved as you go.
What you are about to study
Slack explains a real system. You should know the basics: caching, queues and replication.
Ideas you will meet
- Distributed Systems
- Consensus, time, failure and the fundamentals of scale-out.
What we already know about this
Our own lessons on these ideas. Read them here before you start, so it makes sense.
Low-Level Design Practice · 11 minParking lotVehicles, spots, tickets and fees: a classic exercise in allocation, pricing rules and concurrent entry gates.Read here
The problem
Design a parking lot with several levels. It accepts motorcycles, cars and buses; assigns the nearest suitable free spot on entry; tracks occupancy; and charges a fee on exit by duration and vehicle type. Several entry and exit gates work at once.
Entities
Class Responsibility ParkingLotOwns the levels and gates; entry point for park and unpark LevelA floor holding spots; answers "which free spot fits this vehicle" ParkingSpotHas a type and occupied state; can be reserved and freed VehicleBase type with subclasses or a type field (motorcycle, car, bus) TicketCreated on entry: vehicle, spot, entry time PricingStrategyTurns a stay (duration, vehicle type) into a fee 100%Figure SDA-LLD-02-1 · Parking lot class structure · © forcsguy.com
The entry and exit flow
100%Figure SDA-LLD-02-2 · Entry and exit sequence · © forcsguy.com
Key code
type SpotType = "MOTORCYCLE" | "COMPACT" | "LARGE"; const fits: Record<string, SpotType[]> = { MOTORCYCLE: ["MOTORCYCLE", "COMPACT", "LARGE"], CAR: ["COMPACT", "LARGE"], BUS: ["LARGE"], }; class ParkingSpot { occupied = false; constructor(readonly id: string, readonly type: SpotType) {} tryReserve(): boolean { // atomic in a real system (lock or compare-and-set) if (this.occupied) return false; this.occupied = true; return true; } free() { this.occupied = false; } } class Level { constructor(readonly spots: ParkingSpot[]) {} findAndReserve(vehicleType: string): ParkingSpot | null { for (const s of this.spots) if (fits[vehicleType].includes(s.type) && s.tryReserve()) return s; return null; } }The important details are
tryReserve(one winner per spot) and thefitstable (compatibility in one place).Pricing as a strategy
interface PricingStrategy { fee(vehicleType: string, minutes: number): number } const hourly: PricingStrategy = { fee: (t, m) => Math.ceil(m / 60) * ({ MOTORCYCLE: 1, CAR: 2, BUS: 5 } as any)[t], };Swap in a daily cap, a weekend rate or a subscriber discount without touching
ParkingLot.Before: pricing hard-coded in the ticket
100%After: pricing as a strategy
100%What changed
- A new fee rule is a new class, not an edit to old code
- Each pricing rule can be tested alone
- The ticket no longer knows how fees are calculated
Edge cases and extensions
- Lot full:
parkreturns "no spot" cleanly rather than throwing. - Lost ticket: look the vehicle up by plate; charge the maximum rate.
- Nearest spot: keep free spots in a sorted structure per level (a heap or a set per type) so allocation is not a linear scan at scale.
- Display boards that show free counts are observers of spot changes.
- Persistence: if the app restarts, rebuild occupancy from stored tickets.
Real-world reading
Related reading
- Scaling Infrastructure at Twitter - Yao Yue, Staff Software Engineer at TwitterTwitterYouTube
- Scaling Slack - Bing Wei, Software Engineer (Infrastructure) at SlackSlack engineers · SlackCase Studies
- Scaling Gradient Boosted Trees for Click-Through-Rate Prediction at YelpYelp engineers · YelpCase Studies
- Building Real Time Infrastructure at Facebook - Jeff Barber and Shie Erlich, Software Engineer at FacebookFacebook engineers · FacebookCase Studies
Show 6 moreShow fewer
- Software Engineering DailySoftware Engineering DailyPodcasts & Newsletters
- Scaling Pinterest - Marty Weiner, Pinterest’s founding engineerYouTubeYouTube
- Design Patterns CatalogueRefactoring GuruDocumentation
- PricingNet: Pricing Modelling with Neural Networks at SkyscannerSkyscanner engineers · SkyscannerCase Studies
- Software Engineering Advice from Building Large-Scale Distributed Systems - Jeff DeanGooglePapers
- Software Engineering RadioIEEE Computer Society · SE RadioPodcasts & Newsletters
Go deeper on this
A path through videos, articles, other case studies and code on the same ideas as Scaling Slack - Bing Wei, Software Engineer (Infrastructure) at Slack.
Warm upGet the vocabulary first.
Books · Free from the author
Concurrent and Distributed Systems (Cambridge lecture notes)
Eight lectures on time, broadcast, replication, consensus and transactions, with notes, slides and video. Free from the author under CC BY-SA.
University of CambridgeIntermediate
Books · Free from the author
Computer Networks: A Systems Approach
How networks are built and why: protocols, routing, congestion control and the internet's architecture. The authors publish it free online under CC BY 4.0.
Systems ApproachIntermediate
WatchHow others solve the same problem, on video.
Videos belong to their creators and play from YouTube. More on YouTube (opens in a new tab)
ReadEngineers explain it in their own words.
Blogs · Free from the author · Read here
Scalable Web Architecture and Distributed Systems
A full chapter on the building blocks of large websites: availability, performance, reliability, scalability, caches, proxies, indexes, load balancers and queues. Free to read here under CC BY 3.0.
The Architecture of Open Source ApplicationsBeginner40 min
Papers · Read here
Facebook’s photo storage
This paper describes Haystack, an object storage system optimized for Facebook’s Photos application. Facebook currently stores over 260 billion images, which translates to over 20 petabytes of data.
USENIXIntermediate
See it in another companyThe same ideas, a different system.
Case Studies · Read here
Aroma: Using ML for Code Recommendation at Facebook
Thousands of engineers write the code to create our apps, which serve billions of people worldwide. This is no trivial task—our services have grown so diverse and complex that the codebase contains…
FacebookIntermediate
Case Studies · Read here
Brooklin: Distributed Service for Near Real-Time Data Streaming at LinkedIn
Brooklin—a distributed service for streaming data in near real-time and at scale—has been running in production at LinkedIn since 2016, powering thousands of data streams and over 2 trillion messages per day. Today, w...
LinkedInIntermediate
Read the codeSee how it looks when it is real.
GitHub
Engineering Blogs
A huge directory of company engineering blogs to learn from real production systems.
kilimchoiIntermediate
GitHub
Awesome Scalability
Curated reading list of articles on the architecture of scalable, reliable systems.
binhnguyennusIntermediate
Keep learning
Loading community…