DoorDash Staff Full-Stack Developer Interview Preparation Guide

Design overview
Minimal REST surfaced by Orders service; Courier service (discovery/availability) and Notification service handle nearby courier lookup and delivery of push/WS messages. Use event-driven updates (webhooks or pub/sub) for scale.

Endpoints

1. Create order
   POST /orders
   Request:

{
  "user_id":"u_123",
  "pickup": {"lat":37.77, "lng":-122.41, "address":"1 Market St"},
  "dropoff": {"lat":37.79, "lng":-122.40, "address":"100 Pine St"},
  "items":[{"id":"i1","qty":2}],
  "priority":"normal",
  "requested_eta_mins":30
}

Response:

{
  "order_id":"o_456",
  "status":"searching_courier",
  "created_at":"2026-03-03T12:00:00Z"
}

Action: Orders service calls Routing/Courier service with pickup location + constraints to get eligible couriers (radius, capacity, status). Then calls Notification service to push an offer.

2. Notify courier (internal; from Orders -> Notification)
   POST /internal/notifications/courier-offer

{
  "courier_id":"c_789",
  "order_id":"o_456",
  "pickup":{"lat":37.77,"lng":-122.41},
  "dropoff":{"lat":37.79,"lng":-122.40},
  "expires_at":"2026-03-03T12:02:00Z"
}

3. Courier accepts/rejects
   POST /orders/{order_id}/offers/{courier_id}/response

{
  "courier_id":"c_789",
  "response":"accept"   // or "reject"
}

Response:

{
  "order_id":"o_456",
  "courier_id":"c_789",
  "result":"accepted",
  "assigned_at":"2026-03-03T12:01:10Z"
}

4. Order status lookup
   GET /orders/{order_id}
   Response includes routing fields to help UI:

{
  "order_id":"o_456",
  "status":"assigned | searching_courier | cancelled",
  "assigned_courier":{"id":"c_789","eta_mins":5},
  "offers":[{"courier_id":"c_101","state":"pending","expires_at":"..."}]
}

Key fields for routing & tracking

• pickup/dropoff lat,lng (routing)
• user_id, order_id (correlation)
• priority/constraints (capacity, vehicle_type)
• offer_id or courier_id + expires_at (race/timeout handling)
• assigned_at, status, offered_at (audit)

Notes / reasoning

• Keep synchronous create lightweight; asynchronously fan-out offers.
• Use short TTL on offers to avoid races; first accept wins (Orders service enforces compare-and-set/DB transaction).
• Internal endpoints marked /internal to separate microservices and auth.
• Use pub/sub for large scale (Notifications subscribe to courier-offer events).

Direct answer

pg_stat_activity is a system view, one row per active database connection (called a backend), showing what that connection is doing right now: its process ID, current state, what it's waiting on if anything, when its current query started, where it connected from, and the query text itself. It's the first place I look to answer "what is the database doing at this exact moment," especially for finding queries that have been running too long or sessions that are blocking each other.

Structured elaboration

Reading the key columns.

• pid: the backend's process ID. This is the identifier you'd pass to pg_cancel_backend(pid) (asks the query to stop, like a graceful interrupt) or pg_terminate_backend(pid) (forcibly ends the whole connection) if you decide to intervene.
• state: the backend's overall status. active means it's currently executing a query. idle means it's connected but waiting for the application to send the next command. idle in transaction is the one worth watching closely: a transaction is open but nothing is currently running inside it, which usually means application code forgot to commit or roll back, and it can hold locks the whole time it sits idle.
• wait_event_type and wait_event: if the backend isn't just burning CPU, these say what it's blocked on. A Lock wait means it's waiting on another session (contention); an IO wait means it's waiting on a disk read or write; a Timeout wait with event PgSleep means, unsurprisingly, it's inside a pg_sleep() call.
• query_start: when the currently running statement started. Subtracting this from now() gives you how long the current query has been running, which is the basis for the "longer than 5 minutes" filter below.
• client_addr: the IP address the connection came from. If this is null, it means the connection came in over a local Unix socket on the database server itself, not that the information is missing; a lot of same-host tooling and some connection poolers connect this way.
• application_name: whatever the connecting application chose to set it to (most drivers let you set this in the connection string). It's the single most useful column for triage in a system with more than one application talking to the database, because it turns an anonymous process ID into "this is the reporting job" or "this is the checkout service."

The query.

SELECT pid,
       state,
       wait_event_type,
       wait_event,
       query_start,
       now() - query_start AS running_for,
       client_addr,
       application_name,
       left(query, 80) AS query
FROM pg_stat_activity
WHERE now() - query_start > interval '5 minutes'
  AND state <> 'idle'
  AND pid <> pg_backend_pid()
ORDER BY query_start;

pid <> pg_backend_pid() excludes the very session running this query, since that query obviously isn't "long-running" relative to itself. Filtering state <> 'idle' keeps the result set to sessions actually doing something (a genuinely idle connection sitting there for hours isn't the problem this query is hunting for; idle in transaction for a long time is, and it passes the filter because its state literally is idle in transaction, not idle).

Worked example

I ran this against a real PostgreSQL 16 instance seeded with 2 million rows. I started a background session that set its application_name to reporting-svc and ran SELECT pg_sleep(20), count(*) FROM orders WHERE status = 'paid', then queried pg_stat_activity from a second session two seconds in (using a 1-second threshold instead of 5 minutes purely so the demo doesn't require an actual 5-minute wait; the query shape is identical). The real output:

 pid | state  | wait_event | query_start                    | running_for     | client_addr | application_name | query
-----+--------+------------+---------------------------------+------------------+-------------+------------------+-------------------------------
  74 | active | PgSleep    | 2026-09-25 05:05:49.564188+00 | 00:00:02.085267 |             | reporting-svc    | SET application_name = 'reporting-svc'; select pg_sleep(20),

Reading this row: pid 74 is the one to act on if I decide to cancel it. state is active, so it's genuinely executing, not idle in a transaction. wait_event is PgSleep, confirming it's inside the sleep, not blocked on a lock or I/O (in a real slow query you'd instead see either no wait event at all, meaning it's CPU-bound, or an IO event like DataFileRead, meaning it's waiting on disk). client_addr is blank, which by the definition above means this connected over a local Unix socket, not that I'm missing data. application_name immediately tells me this is the reporting service, not, say, the checkout path, which changes how urgently I'd intervene.

Trade-offs and pitfalls

pg_stat_activity shows the currently executing statement, not the whole transaction's history, so a session that ran three fast statements and is now stuck idle in a fourth, uncommitted transaction will show idle in transaction with an old xact_start but a recent-looking query_start from its last completed statement; check xact_start as well as query_start when a session looks suspicious. The query text shown is the literal text sent by the client, including any parameter placeholders the driver already substituted, so very generic-looking queries from an object-relational mapper (ORM, a library that translates between database rows and application objects) can be hard to trace back to a specific code path from the text alone; application_name and a request or correlation ID embedded in a SQL comment (many ORMs support this) close that gap. Running this query itself has negligible cost, but reflexively killing every session with pg_terminate_backend the moment it shows up in a long-running query check is a mistake: a five-minute analytical report or a maintenance job (like a VACUUM) is legitimately long-running, and killing it mid-write can force a rollback that costs more time than letting it finish.

Direct answer. REST for the public partner API (broad client reach, cacheability, and simplicity matter most and you cannot control what partners' HTTP tooling supports); gRPC for the internal high-throughput service mesh (binary framing, streaming, and generated strongly-typed clients matter more than human-readability once every caller is a service you control); and REST, or GraphQL if the client genuinely needs to shape a nested response itself, for the unreliable mobile client, prioritizing tolerance of dropped connections and minimizing round trips over raw throughput.

Comparison across the five axes.

• Caching: REST's biggest structural advantage. A GET request maps naturally onto HTTP caching (Cache-Control, ETag, CDN edge caching) because the URL itself identifies the cacheable resource. GraphQL's single POST-based endpoint and gRPC's binary RPC calls both defeat generic HTTP caching by default; both need a purpose-built caching layer if they want it at all.
• Client flexibility: GraphQL wins outright, since the client specifies exactly which fields it wants in one round trip; REST either over-fetches (returns the whole resource) or requires bespoke ?fields= parameters per endpoint; gRPC returns whatever the fixed protobuf schema defines, no client-side shaping at all.
• Network overhead: gRPC wins, using compact binary Protocol Buffers (a binary message format — smaller on the wire and faster for both sides to parse than text-based JSON, at the cost of not being readable directly in a browser's network tab) over HTTP/2 multiplexing (many requests and responses share one underlying connection at the same time, instead of the client opening a new connection per request); REST and GraphQL both typically ship JSON, which is larger and slower to parse, though GraphQL's field-selection can reduce payload size by avoiding over-fetch even with the same wire format.
• Versioning: REST has the most established conventions (URI/header/media-type, well understood by every client). GraphQL favors additive, non-breaking schema evolution with field deprecation over versioned endpoints entirely. gRPC's protobuf has strict, well-defined field-numbering rules for safe evolution, but breaking those rules (reusing a field number) is a hard, occasionally very difficult to detect production bug.
• Developer ergonomics: REST is the lowest common denominator, understood by literally every HTTP client, browser dev tool, and API testing tool with zero extra tooling. GraphQL and gRPC both need generated client code or specialized tooling to get real ergonomic benefit, which is friction for a public partner integration but a non-issue for an internal service mesh where every caller already runs your codegen pipeline (codegen — client-side code automatically generated from the service's schema, rather than hand-written by each team calling it).

Applying this to the three scenarios. A public partner API optimizes for the lowest integration cost for partners you do not control and for free CDN caching; REST wins on both. An internal high-throughput mesh optimizes for raw efficiency between services you fully control and can codegen against; gRPC wins. A mobile client on unreliable networks optimizes for minimizing round trips and tolerating partial failure; either a well-designed REST API with sparse fieldsets (a ?fields= query parameter letting the client name only the fields it actually needs back, so the server skips returning the rest of the resource), or GraphQL if the client's data needs are genuinely nested and variable screen-to-screen, both beat a chattier multi-call REST design, and gRPC's lack of native browser/mobile-friendly tooling (without a gRPC-Web proxy layer — an extra translation service that sits in front of gRPC, since a browser cannot speak raw HTTP/2 gRPC directly) makes it the weakest fit here despite its raw efficiency.

Trade-offs and pitfalls. The mistake to avoid is picking one paradigm company-wide "for consistency"; the three scenarios above genuinely optimize for different things, and a mesh forced into REST-for-consistency pays a real latency and serialization cost with no corresponding benefit, just as a public API built in gRPC for consistency loses the free caching and universal client support that made REST the right call there.

Direct answer

Use a STAR structure (Situation, Task, Action, Result), but because this question is specifically
about a failure to act, the "Action" section should center on what you did NOT do and, honestly,
why you hesitated, followed by a Result that names the concrete cost and a closing Learned section
that describes a specific process change, not just a resolution to behave differently.

STAR skeleton to fill in

• Situation: describe the ambiguous context. What made ownership unclear (no assigned owner,
  a gap between two teams, an assumption that someone else was covering it)?
• Task: what decision or action actually needed to happen, and by when?
• Action (framed as inaction): what you noticed, what you did not do, and the specific reason
  you hesitated. Common honest reasons: assuming another team or person owned it, worrying that
  raising it without full information would look like overreacting, or not having clear authority
  to act and not seeking it out.
• Result: the concrete, ideally quantified consequence of the delay.
• Learned and changed: what the hesitation revealed about a gap in the system (not just in your
  personal courage), and the specific, durable change you made to your process so the same gap
  wouldn't cause the same outcome again, even if the same hesitation impulse showed up.

Worked example instance

Situation: midway through a project, a vendor silently renamed a field in a data contract two
weeks before a hard external launch date. Task: someone needed to notice the change and decide
whether to patch the integration or escalate for a possible delay. Action (inaction): I
noticed the anomaly in a routine data check but assumed the vendor's account manager, or another
team lead who worked more closely with that vendor, would flag it and own the fix; I also worried
that raising it without being fully sure it was a real issue would look like overreacting to a
non-problem. Result: the renamed field silently defaulted to null for nine calendar days
(basis: from the date of the schema change to the date the break became visible to a customer)
before a downstream report broke in front of that customer. We ran an emergency data backfill over
a weekend, and the customer's renewal conversation was pushed back three weeks while we rebuilt
trust. Learned and changed: the real gap wasn't that the vendor did something wrong, it was
that "notice this kind of anomaly and act on it" had no assigned owner in the space between the two
teams, and the default human response to that kind of ambiguity is to assume someone else has it.
I implemented a lightweight schema-diff monitor that pages a specific, named on-call person (not a
team inbox) whenever an upstream data contract changes, and I personally adopted a rule: if
something looks like "someone else's job" and I don't see visible action on it within one business
day, I either claim it myself or explicitly hand it to a named person with a deadline, rather than
silently assuming it's covered.

What separates a strong answer from a mediocre one here

A mediocre answer stays vague ("I should have communicated more"), quietly shifts blame outward
(focusing on what the vendor did wrong rather than the candidate's own hesitation), offers a
"lesson learned" that's just a personal resolution with no system behind it ("I learned to speak
up"), or picks an example where the stakes were low enough that "the outcome suffered" doesn't
really hold up. A strong answer names the actual reason for the hesitation honestly (not "I was
busy," but something closer to the real psychological or organizational cause), quantifies the
cost, and produces a change that would prevent the same failure mode even if the same instinct to
assume someone else has it shows up again, because that's what shows the lesson was structural, not
just a promise to try harder.

Second, shorter example (different discipline): the same shape shows up in a marketing
scenario where nobody explicitly owned verifying that a competitor's advertised price change was
real before a promotional campaign launched around it; the fix wasn't "communicate better," it was
assigning a named owner for competitive-claim verification with a required sign-off before any
campaign referencing a competitor goes live.

Trap to avoid

Don't answer this as "tell me about a time I made a mistake" in general. The question specifically
asks about a failure to take ownership under ambiguity, so the hesitation itself, not just the
error, needs to be the center of the story.

Plain exponential backoff (double the delay after each failed attempt) reduces load on a struggling dependency over time, but it has a hidden flaw: if many clients failed at roughly the same moment (which is exactly what happens when the dependency itself goes down), they all compute the same delay sequence and retry in lockstep, so the "backoff" just delays the same synchronized spike instead of spreading it out. Jitter fixes that by randomizing the delay so clients that failed together don't retry together.

Jitter strategies compared

Worked example: how much jitter actually reduces the spike

Pin a concrete scenario: 1000 clients failed at the same moment, base delay = 1 second, and this is their 3rd retry attempt (attempt = 3), so the backoff cap is:

Without jitter: every one of the 1000 clients computes the identical 8-second delay and retries at exactly the same instant, a spike of 1000 concurrent requests hitting the dependency in one moment, right as it may just be starting to recover.

With full jitter, each client independently draws a delay uniformly from $[0, 8]$ seconds. Dividing that 8-second window into 100 ms buckets gives $8000 / 100 = 80$ buckets, and under a uniform distribution the expected number of clients landing in any single bucket is:

That's a peak-to-average reduction factor of $1000 / 12.5 = 80\times$ under this modeling assumption (uniform, independent draws), turning one instantaneous spike of 1000 into a smooth trickle of roughly 12-13 requests every 100 ms across the full 8-second window, which a recovering dependency can absorb where a single 1000-request spike would knock it back down.

Why retries shouldn't make recovery worse

Jitter alone doesn't prevent the retry storm from getting worse over time if attempts aren't capped: a client that keeps failing and keeps retrying at $\text{base} \times 2^{\text{attempt}}$ forever will eventually be sending requests at a cap so large it's functionally giving up, or, worse, if the cap is bounded, converges back to a steady drumbeat of load that never lets the dependency fully recover. The fix is a hard cap on both the maximum delay and the maximum number of attempts, plus honoring any explicit signal the server provides (a Retry-After header or a 429/503 status) as authoritative over the client's own backoff schedule, since the server is in the best position to know its own recovery state.

Trade-offs and pitfalls

Full jitter maximizes spread but means some unlucky clients draw a near-zero delay and retry almost immediately, which is fine in aggregate (that's still only ~12-13 requests per 100ms bucket in the example above) but means full jitter alone doesn't guarantee a minimum backoff for any individual client; equal jitter trades some of that spread for a guaranteed floor, useful when even a small number of near-instant retries is unacceptable. A pitfall specific to mobile or otherwise unreliable-network clients: retries are only safe to jitter and reattempt if the underlying operation is idempotent (repeating it produces the same end result as doing it once, so a duplicate attempt is harmless), a non-idempotent submit (a payment, an order) retried after a client-side timeout can double-execute if the server had actually processed the first attempt and just failed to deliver the response, so the fix belongs on the server (idempotency keys deduping identical requests) not just in the client's backoff logic, jitter reduces load, it does not make an unsafe retry safe.

Direct answer

Scan the expression once left to right, accumulating the current number and, on hitting an operator (or the string's end), resolving the previous operator against a value stack rather than a running total directly. Addition and subtraction push a signed value onto the stack to be settled later; multiplication and division pop the stack's top, combine it with the current number immediately, and push the result back, because those two operators must bind tighter than whatever addition or subtraction comes before or after them. The stack is what lets the scan defer every addition and subtraction until the very end, once every higher-precedence operation touching a given operand has already been folded in, summing the stack at that point gives the correct, precedence-respecting result.

Structured elaboration

Why a single accumulator is not enough

Evaluating left to right with one running total works for pure addition and subtraction, but multiplication and division must apply to their immediate neighbors before anything else touches those values. A single accumulator has no way to "undo" a value it already folded into the total in order to multiply it by something appearing later.

What the stack defers, specifically

Each time a complete number is read, look at the operator that preceded it:

• +: push the number as-is; it will be added in at the end.
• -: push the number negated; subtraction is addition of a negative.
• * or /: pop the stack's current top, combine with the new number right now, and push the combined result back, this is what "deferring lower-precedence operations" really means in reverse: it is addition and subtraction that get deferred, while multiplication and division are resolved immediately because their operands are already fully known.
  At the very end, summing the whole stack applies every deferred addition and subtraction in one shot, correctly, because every *// touching any of those values has already been folded in before it ever reached the stack.

Handling division sign and formatting

Division must truncate toward zero (not Python's default floor division, which rounds toward negative infinity for negative operands), so int(a / b) rather than a // b is used to match the conventional integer-arithmetic contract.

Worked example

def calculate(s: str) -> int:
    s = s.strip()
    stack = []
    num = 0
    op = '+'
    n = len(s)
    for i, ch in enumerate(s):
        if ch.isdigit():
            num = num * 10 + int(ch)
        if (not ch.isdigit() and ch != ' ') or i == n - 1:
            if op == '+':
                stack.append(num)
            elif op == '-':
                stack.append(-num)
            elif op == '*':
                stack.append(stack.pop() * num)
            elif op == '/':
                prev = stack.pop()
                stack.append(int(prev / num))
            op = ch
            num = 0
    return sum(stack)

print(calculate("3+2*2"))
print(calculate(" 3/2 "))
print(calculate(" 3+5 / 2 "))
print(calculate("14-3/2"))
print(calculate("1*2-3/4+5*6-7*8+9/10"))

This prints:

7
1
5
13
-24

Tracing "3+2*2": read 3, hit +, push 3 (stack [3]), op becomes +. Read 2, hit *, push 2 (stack [3, 2]), op becomes *. Read the final 2 (end of string triggers resolution with op = '*'): pop 2, multiply by the new 2, push 4 (stack [3, 4]). Sum is 7, matching the printed output. "14-3/2" similarly resolves 3/2 to 1 via truncating division before the pending subtraction is ever applied, giving 14 - 1 = 13.

Key points

• The stack holds fully-resolved, precedence-correct terms; the final sum() is the only place addition and subtraction actually happen across terms.
• * and / never get their own stack entries, they immediately combine with whatever the stack's top already holds.
• Multi-digit numbers accumulate via num = num * 10 + int(ch) before any operator triggers resolution.

Complexity

Time: $O(n)$, a single pass over the string. Space: $O(n)$ in the worst case for the stack (an expression that is entirely additions and subtractions of single terms pushes one entry per term), though it can be reduced to $O(1)$ extra space by tracking only the running total and the most recent term instead of a full stack, at the cost of a less direct mapping to "what the stack is doing" pedagogically.

Edge cases

• Leading, trailing, or embedded spaces: skipped by the ch != ' ' check, which does not trigger a resolution and does not get added into the accumulating number.
• Multi-digit numbers: accumulated digit by digit before any operator resolves them.
• Expression ending exactly on a number (no trailing operator): the i == n - 1 condition forces one final resolution using whatever operator preceded that last number.
• Division truncating toward zero for negative results: using int(prev / num) rather than prev // num avoids Python's floor-toward-negative-infinity behavior on mixed-sign division.

Trade-offs & pitfalls

The most common bug is using // for division and getting a different (floored, not truncated) result on negative operands; int(a / b) sidesteps this by truncating through the int() conversion itself. A frequent design question is whether to extend this to full recursive-descent parsing to support parentheses and unary operators (Basic Calculator III-style): the single-pass stack approach generalizes naturally to nested parentheses by recursing into a sub-expression whenever ( is seen and returning the sub-result to the outer scan, whereas true operator-precedence parsing with a formal grammar is a more general (and more code-heavy) solution better suited to expressions with many operator types or user-defined precedence rules.

Direct Answer

Two-phase commit (2PC) is a protocol that lets one coordinator get a group of participants, each owning a different resource such as a database or another service acting as a resource manager, to commit or abort a single transaction atomically. It works by first asking everyone to prepare, and only telling everyone to actually commit once every participant has confirmed it's ready.

The Two Phases

• Prepare (vote) phase: the coordinator sends Prepare to every participant. Each participant does whatever local work is needed to guarantee it can commit if told to, such as writing an undo or redo log entry, acquiring the necessary locks, or checking constraints, then replies Yes or No. Once a participant votes Yes, it must hold its prepared state and locks until it hears the final decision; it can no longer unilaterally change its mind.
• Commit/abort phase: if every participant voted Yes, the coordinator sends Commit to all of them; if any participant voted No, or didn't respond, it sends Abort to all of them. Each participant applies the decision and releases its locks.

The Classic Blocking Failure

If the coordinator crashes after collecting Yes votes from every participant but before sending out the final Commit or Abort, every participant is stuck holding its prepared state and its locks indefinitely. A participant can't safely decide on its own: if it guesses Commit but the coordinator, once recovered, had actually decided Abort because some other participant it hadn't heard from yet said No, that guess would violate atomicity. So each participant has no safe choice but to wait.

This is a real operational problem, not just an inconvenience, because those held locks are on real resources. Any other transaction that touches the same rows, files, or records is blocked too, for as long as the coordinator stays down. A single stuck 2PC transaction can produce an effective outage across everything those locks reach.

A Mitigation: Durable Coordinator Logging and Recovery

The coordinator writes its decision, and the votes it collected, to a durable write-ahead log, a log written to disk before the coordinator acts on it so it survives a crash, before sending Commit or Abort. On restart, or when a replacement coordinator takes over, elected through its own consensus mechanism, it replays that log to learn what it had already decided for any in-flight transaction and resends the correct outcome to whichever participants are still blocked. This doesn't remove the blocking window entirely, but it bounds it to however long recovery takes, instead of leaving participants blocked forever.

Worked Trace

Three participants: a relational database (DB), a document store (Doc), and, for illustration, a payment gateway wrapped with a prepare step (PG). Coordinator C.

1. C sends Prepare to DB. DB validates and locks, replies Yes.
2. C sends Prepare to Doc. Doc validates and locks, replies Yes.
3. C sends Prepare to PG. PG validates, replies Yes.
4. C now has 3 of 3 Yes votes and is about to send Commit, but it crashes before sending anything.
5. DB, Doc, and PG are all blocked, each holding its prepared locks; none of them can safely commit or abort on its own, since each only knows its own vote was Yes, not the others'.
6. A recovered, or replacement, coordinator reads its durable log, sees that all three votes were Yes and that Commit was the decision about to be sent, and resends Commit to DB, Doc, and PG. All three commit and release their locks.

Heterogeneous Resources and a Real-World Wall

2PC's coordinator and participant model works across different kinds of resources in principle: a relational database and a document store can both act as participants as long as each exposes a real prepare step, which is exactly what the XA standard, the X/Open standard defining a two-phase-commit interface for resource managers, formalizes for relational databases. The practical wall most teams hit is that an external payment gateway typically doesn't expose anything like a prepare/commit interface at all; it's a single, irrevocable HTTP call. That's one concrete reason a workflow like reserve inventory, charge card, and ship is usually built as a saga rather than a literal distributed transaction: at least one of the participants can't be plugged into 2PC as a real participant.

When to Reach for a Saga Instead

Reach for a saga instead of 2PC when at least one step can't participate in a real prepare/commit handshake, such as a third-party API with only a single irreversible call, when holding locks for the full duration of the workflow is unacceptable for availability or latency, or when some steps are long-running, such as waiting on a person, a batch job, or a slow downstream service, and you can't justify holding resources locked that long.

Trade-offs and Pitfalls

• A common wrong turn is assuming a participant can unilaterally abort on its own after a timeout once it has already voted Yes. It can't, safely, because it doesn't know whether the coordinator already told everyone else to commit; that's exactly why 2PC is called blocking.
• Presumed-commit and presumed-abort optimizations reduce how much needs to be logged in the common case, but they don't remove the fundamental blocking window; they just make the typical path cheaper.
• Three-phase commit adds an extra round specifically to shrink this blocking window, but it doesn't fully eliminate it, and it's rarely deployed in practice because of the added message and latency cost for a problem that a saga usually sidesteps entirely.

Direct answer

Solo, one week, minimal spec, launch-critical: the plan has to front-load clarifying scope and de-risking the biggest unknown on day one, ship the smallest correct version early, and hold a visible cut-list so a slip becomes a scope decision instead of a missed deadline. The plan below assumes a five-day work week.

Structured elaboration

The shape that makes a solo one-week delivery survivable is: clarify and de-risk early, build the narrowest correct path next, harden and observe before the deadline, and always know what gets cut first if something goes wrong. Acceptance criteria and monitoring have to be decided before day one ends, not discovered on day five, because there is no one else to catch a wrong assumption for you.

Worked example

Day 1: A short conversation with the requester to pin down acceptance criteria and write a one-page mini-spec covering the primary case and the assumptions I'm making, with explicit sign-off. Spend the rest of the day spiking the single riskiest unknown (for example, confirming the actual shape of an upstream dependency's response) before committing to a design around it.

Day 2: Build only the happy path end-to-end, wired behind a feature flag on an isolated branch. No edge cases yet; the goal is one correct path proven working top to bottom.

Day 3: Add handling for the two or three failure modes that actually matter in production, and write automated tests for the happy path plus those failure modes. End of day: a short async or 15-minute check-in with the stakeholder on progress against the day-1 plan.

Day 4: Test against production-like data, wire up monitoring (an error-rate and latency view, with an alert threshold) so day one in production is observable, and do a dry run with a teammate reviewing the diff and the plan.

Day 5: Ship behind the flag to a small slice of traffic first, verify against the acceptance criteria from day 1, then widen. Final checkpoint communication to the stakeholder covering the go/no-go decision and the rollback plan, with buffer time held back in case the initial ramp surfaces something.

Acceptance criteria: correct behavior on the primary path, handling for the top failure modes, monitoring live before go-live, and a documented rollback plan.

Checkpoint schedule: end of day 1 (scope confirmed), end of day 3 (progress check), end of day 5 (go/no-go).

Cut list if blocked, in order: first, secondary or nice-to-have edge cases; second, defer broader test coverage down to just the top failure modes; third, negotiate scope itself (for example, ship only the read path and defer the write path); last resort, tell the stakeholder directly that scope is being cut rather than silently letting the date slip.

Trade-offs and pitfalls

Skipping the day-1 scope conversation to "save time" is the single most common way a solo, tight-deadline effort fails, because any wrong assumption compounds for the rest of the week with no one to catch it. Building broad edge-case coverage before the happy path even works end to end risks having nothing shippable if day 5 arrives early. Waiting until day 5 to think about monitoring means the first production issue is invisible until a user reports it. And having no pre-agreed cut list forces an improvised, worse decision under pressure exactly when there is the least time to make a good one.

Direct answer

Raising isolation level doesn't slow the database down by making individual statements do more work; it slows the database down by turning previously-independent transactions into ones that now wait on each other, or that now sometimes fail outright and have to be retried. Both effects reduce effective write throughput even though the hardware's doing the same amount of underlying work. Diagnosing and fixing it without reverting means narrowing the isolation bump to the specific transactions that actually need it, rather than treating it as a single database-wide setting.

Structured elaboration

Why the regression happens. At Read Committed, two transactions writing to unrelated or lightly-overlapping rows almost never interact; each one takes only the row locks it needs, momentarily, and releases them on commit. Moving to Repeatable Read or Serializable changes that in two distinct ways depending on the engine and level: (a) a transaction's snapshot is now fixed for its whole duration, so if two transactions running concurrently happen to touch the same row, one of them may now be forced into a wait or a conflict it wouldn't have hit under per-statement Read Committed snapshots; (b) at true Serializable specifically, the engine has to track read-write dependencies between transactions (Postgres's predicate locks) and can abort a transaction at commit time for a conflict that was undetectable earlier, meaning some fraction of transactions now do all their work and then get thrown away and have to be retried from scratch, pure wasted throughput. On engines whose Repeatable Read or Serializable is lock-based rather than pure-MVCC (unlike Postgres's snapshot-based Repeatable Read), raising the level can additionally mean writes now take broader locks: a gap lock blocks other transactions from inserting into a range of not-yet-existing rows, and a next-key lock combines that with a lock on the existing row right after the gap (or shared locks on reads under Serializable), and any of these can block other writers outright, not just abort them later.

How to diagnose it, rather than assume. Look for the specific fingerprint of each mechanism: a rising rate of aborted transactions with a serialization-failure SQLSTATE (the five-character error code the database returns with every error, 40001 for a serialization failure) in application logs or pg_stat_database.xact_rollback climbing relative to xact_commit points at (b), retry-driven waste; a rising count of sessions in pg_stat_activity with wait_event_type = 'Lock' points at (a), genuine blocking. Those are different problems with different fixes, so confirm which one is actually happening before changing anything.

Mitigating without simply reverting:

• Scope the isolation bump to the transactions that actually need it, using SET TRANSACTION ISOLATION LEVEL per-transaction rather than a database- or session-wide default. Most of a typical online transaction processing (OLTP) workload doesn't need the stronger guarantee at all; if the change was made broadly "to be safe," narrowing it to the specific write paths with a real cross-row invariant (write-skew risk: two transactions each read a shared condition and write different rows) removes the regression from everything else without giving up the protection where it matters.
• Shrink the transactions that do need the stronger level, so each one holds its snapshot and any locks for less time: split a large multi-statement transaction into the smallest unit that still needs to be atomic, and make sure nothing unrelated (an external API call, an unrelated read) is happening inside the transaction boundary and extending how long it's exposed to conflict.
• Add the indexes the affected queries are missing. A query without a good index scans (and, on lock-based engines, locks) a wider range of rows than the logical operation requires; a targeted index can shrink both the work done and the surface area for conflict.
• Add application-level retry with backoff for the (b) failure mode. If Serializable's abort rate under real contention isn't zero, that's expected; the fix is making sure every write path that can hit it retries automatically and transparently, not treating each abort as an incident.

Trade-offs & pitfalls

• Reverting the isolation change entirely trades away whatever correctness problem it was meant to fix; the mitigations above are worth doing specifically because they let the team keep that protection where it's actually needed while giving it back everywhere else.
• Don't assume the regression is caused by locking without checking; on Postgres specifically, Repeatable Read and Serializable are MVCC-based and non-blocking for reads, so a throughput drop after raising isolation there is more likely retry-driven (mechanism b) than genuinely blocking-driven (mechanism a), which points the investigation at pg_stat_database.xact_rollback before it points at pg_locks.

A bug that only appears under heavy load needs a test harness that can manufacture load deterministically, since waiting for production traffic to happen to trigger it again is not a repeatable investigation.

Building the harness

1. Synthetic traffic generation at a controlled, repeatable concurrency and request mix (a load-testing tool driving realistic request shapes, not just raw throughput).
2. Seed shared state deterministically (fixed starting data, fixed random seeds where the system uses randomness) so the only varying factor between runs is scheduling/timing, not also data variance.
3. Concurrency controls and deterministic schedulers where available, to bias the interleaving toward the suspected contention point rather than relying purely on load volume to eventually hit it.
4. Time manipulation (accelerating or controlling clock-dependent logic) when the bug involves timers, TTLs, or scheduled work, so you don't need to wait real-world hours to observe a time-triggered condition.
5. Minimize noise, prove causality: run the same load profile with and without the suspected contributing factor (a specific code path enabled/disabled, a specific config toggled) and compare failure rates statistically rather than trusting a single run either way.

A concrete run

Suppose the suspected bug is a cache-eviction race that only shows up under heavy concurrent writes. Running the harness at a fixed seed (seed=42) and concurrency=20 reproduces the race 0 times in 50 runs; the same harness at concurrency=200 reproduces it in 12 of 50 runs, a clear, statistically meaningful signal that concurrency level, not chance, drives the failure, and a concrete number, 12 of 50 at 200 versus 0 of 50 at 20, a reviewer can rerun and check rather than take on faith.

Applying this without dedicated load-test infrastructure

A single server that fails intermittently under heavy load, or that can't reproduce in staging, benefits from the cheaper version of the same idea: increase load safely on that one host (careful, bounded synthetic load) while capturing fine-grained logs/traces, rather than waiting for the next natural production spike.

Trade-offs and pitfalls

Synthetic load rarely matches production traffic shape exactly (arrival patterns, payload variety, cache warmth); the harness's value is in reliably reproducing the class of failure for iteration, not necessarily reproducing the exact production timeline, so a fix validated only against synthetic load still needs confirmation against real traffic before being called durable.