The Physics of Billion QPS

When people hear “a billion queries per second,” the number feels abstract. Let me make it concrete.

The Scale Problem

At Meta, MySQL isn’t just a database — it’s the backbone of the social graph. Every like, comment, message, and story triggers queries that fan out across thousands of database instances.

SELECT user_id, post_id, reaction_type
FROM reactions
WHERE post_id IN (
    SELECT post_id
    FROM feed_items
    WHERE user_id = ?
    AND created_at > NOW() - INTERVAL 24 HOUR
)
ORDER BY created_at DESC
LIMIT 100;

This single feed query, multiplied by billions of users, is where the physics of scale begins to matter.

The Architecture

Scaling to billion QPS requires rethinking every layer:

// Connection pooling at scale - every microsecond counts
type ConnPool struct {
    mu       sync.RWMutex
    conns    []*sql.Conn
    maxIdle  int
    maxOpen  int
    lifetime time.Duration
}

func (p *ConnPool) Get(ctx context.Context) (*sql.Conn, error) {
    p.mu.RLock()
    if len(p.conns) > 0 {
        conn := p.conns[len(p.conns)-1]
        p.conns = p.conns[:len(p.conns)-1]
        p.mu.RUnlock()
        return conn, nil
    }
    p.mu.RUnlock()
    return p.newConn(ctx)
}

Key Lessons

1. Caching is not optional — At this scale, every query that hits disk is a failure mode.
2. Replication topology matters — The difference between a star and tree topology is the difference between 100ms and 10ms p99.
3. Schema design is forever — At billion QPS, ALTER TABLE is a multi-week project.

What’s Next

In upcoming posts, I’ll dive deeper into:

• Query optimization patterns at Meta scale
• How we handle schema migrations without downtime
• The replication strategies that make billion QPS possible

This is the first in a series on database engineering at extreme scale. Stay tuned.