Course outline

01 · HTTP & REST APIs

02 · Databases & Persistence

03 · Authentication & Authorization

04 · API Design & gRPC

05 · Caching, Queues & Background Jobs

06 · Production-Ready Services

07 · Advanced Auth & Tenant Security

08 · Performance & Caching at Scale

09 · Testing & Release Confidence

Stage 3 · Build

API Design & gRPC

Pagination, Filtering & Sorting

Implement cursor pagination, limit parameters, stable ordering, filters, and total-count tradeoffs.

8 min readBuilding Backend ApplicationsBuild

Pagination Patterns

Every list endpoint needs pagination. Returning all records is not scalable. Two patterns dominate: cursor-based and offset-based. Choose based on your use case.

Pattern	Best For	Tradeoff
Cursor	Infinite scroll, real-time feeds	Cannot jump to page N
Offset	Traditional page navigation	Slow for large offsets

Cursor Pagination

Cursor pagination uses a pointer to the last item. The next request fetches items after that pointer. It handles inserts and deletes correctly — no items are skipped or duplicated.

Gocursor-based-pagination.go

42 linesLn 1, Col 1Go

Fetch limit+1 rows to detect if more results exist. The extra row is discarded. The cursor is the created_at of the last item. Clients pass it as a query parameter.

Offset Pagination

Gooffset-based-pagination.go

26 linesLn 1, Col 1Go

Offset pagination is simple but has a problem: if a row is inserted before the current page, the next page will show a duplicate row. Use cursor pagination for real-time data.

Filtering

Godynamic-query-building.go

30 linesLn 1, Col 1Go

Build the WHERE clause dynamically based on query parameters. Start with WHERE 1=1 to simplify appending AND clauses. Use parameterized queries to prevent SQL injection.

Sorting

Gosafe-sorting-with-allowlist.go

18 linesLn 1, Col 1Go

Never allow user input directly in ORDER BY. Use an allowlist of permitted column names. Default to a safe sort column and direction.

Total Count Tradeoffs

COUNT(*) is expensive on large tables. For millions of rows, it can take seconds. Consider whether clients need an exact total or an approximate one.

Exact total: Run COUNT(*) on every request. Accurate but slow for large tables.
Cached total: Run COUNT(*) periodically and cache the result. Fast but stale.
Approximate total: Use pg_catalog statistics. Fast but imprecise.
No total: Only return has_more. Clients do not know the total count.

Use has_more for infinite scroll

If your UI uses infinite scroll, clients do not need the total count. Return has_more and a cursor. This avoids the COUNT(*) performance hit entirely.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.