Your single PostgreSQL database is reaching its limits. How would you scale reads and then writes, and what problems does each step bring?

What the interviewer wants to hear

• First optimise queries, indexes, connection pooling, vertical scaling
• Read replicas for reads, with replication lag issues
• Caching to reduce load
• Partitioning and sharding for writes, choosing a shard key
• Sharding costs: cross-shard queries, transactions, rebalancing, hot shards

Model answer

Before adding complexity, I would fix slow queries and indexes, add PgBouncer for connection pooling, and scale the machine up, because that solves many problems cheaply. For reads, I would add caching for hot data and read replicas. Replicas are asynchronous, so there is replication lag: a user may update their profile and then read old data from a replica. I handle that by routing reads after a write, or critical reads, to the primary. For writes, a single primary is the limit. I could partition large tables by time, and archive old data. If that is not enough, I would shard by a key such as tenant_id or user_id that keeps most queries on one shard and spreads load evenly. Sharding makes cross-shard joins, transactions, unique constraints and rebalancing hard, and a bad key creates hot shards, so I would consider managed distributed databases too.

More hard Backend Developer questions

• Design a URL shortener like bit.ly that handles 100 million new links per month and many more redirects. Cover IDs, storage, caching and scale.
• A product manager says each payment event must be processed exactly once. How do you achieve that with real message queues and networks?
• In a microservices system, placing an order touches the Order, Payment and Inventory services, each with its own database. How do you keep data consistent?
• You are building a B2B SaaS backend used by many companies. How would you design multi-tenancy and make sure one tenant can never see another tenant data?
• Design a notification service that sends email, SMS and push messages for many products, up to tens of millions of messages a day.
• Your company wants to split a large monolith into microservices. How would you approach it, and when would you argue against it?
• Design the backend for a real-time chat app with one-to-one and group chats, online status and message history.
• One slow downstream dependency caused your whole platform to go down. How would you handle the incident, and what would you change afterwards?
• How would you design a ledger for a wallet or payments product so balances are always correct?