Practice — API Design & Service Communication (6 questions)

A social app exposes GET /users/{id}/feed backed by a Postgres table feed_items(id BIGSERIAL, user_id, created_at, payload) with ~200M rows. Today it uses ?page=N&size=50 (offset pagination). Users report that when they scroll during busy periods they sometimes see the same post twice, and the p99 latency of deep pages (page 400+) is over 2 s.

1. Explain both symptoms mechanically — why duplicates appear and why deep pages are slow.
2. Redesign the endpoint using cursor pagination: specify the query parameters, what the cursor encodes, the SQL the server runs, and the index it needs.
3. What do you lose by switching, and when would you keep offset pagination anyway?

Your API serves 1 billion requests per day.

What's the average requests-per-second — and what number should you actually design for?

Show the conversion, and finish the sizing: how many app servers is that, roughly?