Distributed Systems — Series 2

Preview — 3 of 10 questions

Two users try to edit the same database row at nearly the same time. Compare optimistic and pessimistic locking as strategies to handle this.

APessimistic locking assumes conflicts are rare: it lets both writes proceed and simply keeps whichever one finishes last, silently discarding the other

BOptimistic locking requires taking a full database backup before every write

CBoth strategies are functionally identical — the names just describe the developer's mood while implementing them

DOptimistic locking assumes conflicts are rare: it lets both transactions proceed without blocking, but checks a version number (or timestamp) at commit time — if the row changed since it was read, the write is rejected and must be retried. Pessimistic locking instead assumes conflicts are likely: it locks the row for exclusive access as soon as it's read, forcing other transactions to wait until the lock is released

An API returns paginated results from a table with millions of rows. Compare LIMIT 20 OFFSET 100000 (offset-based) with a cursor-based approach (WHERE id > last_seen_id LIMIT 20).

AOffset-based pagination gets faster as the offset grows, while cursor-based pagination gets slower

BThey have identical performance characteristics at any scale — the choice is purely a matter of API style

COffset-based pagination requires the database to scan and discard all rows before the offset (getting slower as the offset grows), and it can show duplicate or missing items if rows are inserted/deleted between page requests. Cursor-based pagination instead jumps directly to rows after a known key (using an index), keeping consistent performance regardless of how deep the pagination goes, and it's stable against concurrent inserts/deletes

DCursor-based pagination can only be used with NoSQL databases, never with SQL databases

A public API needs to introduce a breaking change without breaking existing client integrations. What are the common approaches to API versioning?

ABreaking changes should simply be deployed immediately to the existing endpoint — clients are expected to update their code within the hour

BAPI versioning is unnecessary as long as the API returns JSON

CCommon approaches include embedding the version in the URL path (/v2/users), in a custom request header (API-Version: 2), or via content negotiation (Accept: application/vnd.api.v2+json) — all of which let old and new clients hit different, coexisting versions of the API so the old version keeps working while clients migrate on their own timeline

DThe only valid way to version an API is to create an entirely separate domain name for every single version

Answer all 10 questions (7 more), see explanations for every answer, and track your score.