DoorDash Staff Software Engineer Interview Preparation Guide

Direct answer

Count every character's frequency in one pass (a hash map or Counter), then make a second pass over the string returning the first character whose count is exactly 1. This is $O(n)$ time and $O(k)$ space, where k is the number of distinct characters. If the string arrives one character at a time and you must be able to answer "what's the first non-repeating character so far" at any point, keep a queue of once-seen candidates in arrival order and evict its front whenever that character's count rises above 1.

Structured elaboration

Two-pass approach, for a string you already have in full:

from collections import Counter

def first_non_repeated(s):
    """
    Return first non-repeated character in s, or None if none exists.
    Two-pass approach: O(n) time, O(k) space (k = distinct characters).
    """
    if not s:
        return None
    counts = Counter(s)
    for ch in s:
        if counts[ch] == 1:
            return ch
    return None

Streaming variant. The two-pass approach needs the whole string up front. If characters arrive one at a time and a query can land at any point, you cannot afford to rescan everything seen so far on every query. Instead, maintain a frequency map alongside a queue (double-ended queue) of characters that are currently unique, in the order they first appeared:

from collections import deque

class StreamingFirstNonRepeated:
    """
    Streaming variant: feed one character at a time via .push(ch) and query
    .current() at any point without rescanning history. O(1) amortized time
    per pushed character (each character enters and leaves the deque at most
    once), O(k) space for k distinct characters seen so far.
    """
    def __init__(self):
        self.counts = {}
        self.q = deque()

    def push(self, ch):
        self.counts[ch] = self.counts.get(ch, 0) + 1
        if self.counts[ch] == 1:
            self.q.append(ch)
        while self.q and self.counts[self.q[0]] > 1:
            self.q.popleft()

    def current(self):
        return self.q[0] if self.q else None

The queue's front is always the earliest-arrived character that is still unique, because any character that becomes non-unique gets evicted from the front the moment its count rises above 1 (it may sit behind the front briefly until it becomes the front, but it is removed by the time it would otherwise be reported).

Worked example

s = "swiss"
print(first_non_repeated(s))

tracker = StreamingFirstNonRepeated()
running = []
for ch in s:
    running.append(ch)
    tracker.push(ch)
    print(''.join(running), '->', tracker.current())

Output:

w
s -> s
sw -> s
swi -> s
swis -> w
swiss -> w

The full-string answer is w, matching the streaming tracker's final answer. Along the way you can see the answer change: after "s", "sw", "swi" the answer is still s (unique so far); once the second s arrives ("swis") the tracker evicts s from the front and reports w; the final s in "swiss" doesn't change the answer since w is still unique.

Trade-offs & pitfalls

Key points

• The two-pass approach is the simplest correct solution when the full string is available; don't reach for the streaming version if you don't need "answer at any point in time" semantics, since it adds a queue and eviction logic for no benefit.
• The streaming approach never needs to rescan from the start, but it does need to keep counts for every distinct character seen so far, and the queue can (temporarily) hold characters that later get evicted, so peak memory is still O(k) not O(1).
• Multi-codepoint or combined Unicode characters (for example, accented characters built from a base character plus a combining mark) are treated as separate codepoints by both approaches; if the requirement is "first non-repeating user-visible character" rather than "first non-repeating codepoint," you would need a grapheme-aware library instead of iterating raw codepoints.

Complexity

• Two-pass: time $O(n)$, space $O(k)$.
• Streaming: $O(1)$ amortized time per pushed character (each character is added to and removed from the queue at most once), space $O(k)$ for the counts and queue combined.

Edge cases

• Empty string: both approaches return None.
• All characters repeated: both return None (the two-pass loop finds no count-1 character; the streaming queue empties out).
• Single character: trivially non-repeating, both return it.

Direct answer
Different companies score behavioral interviews against an explicit, published list of values or principles (Amazon's Leadership Principles, Google's culture questions, Netflix's Freedom and Responsibility framing, and many others). The preparation move is building a small inventory of six to ten real stories from your own work, tagging each with the one or two principles it most naturally demonstrates, then rehearsing them so they sound like your own voice, not the company's marketing language.

Structured elaboration

1. Research the company's actual, current published list. Read the real wording rather than a paraphrase from a prep article, since the specific phrasing often matters to how an interviewer will probe.
2. Build a story inventory before the interview: six to ten stories spanning different situations (a technical trade-off, a conflict, a mistake, a moment you led without formal authority, a customer-facing choice).
3. For each story, identify which one or two principles it most naturally supports. Resist forcing a story to fit a principle it doesn't genuinely show; a shallow fit is easy for an experienced interviewer to spot.
4. Rehearse the story itself, not a script that names the principle repeatedly. A good answer demonstrates the principle through the actions and choices described, and lets the interviewer recognize it.
5. Prepare to reframe the same story around a different principle if asked. Candidates who over-fit one story to one principle tend to struggle when a panel probes for a different angle.

Worked example
A candidate has a story about shipping a feature despite pushback. A first-draft framing centers on: "I pushed hard to get the feature out on time." A more principle-authentic framing, for a company whose stated principle is customer focus, instead leads with the evidence: "Support tickets showed users were repeatedly confused by the old flow, so I made the case that shipping on time mattered less than shipping the right fix, and I only pushed for speed once we had confirmed the new version actually addressed what customers were reporting." The underlying facts are identical; the second version leads with the customer evidence, which is what makes it read as authentic to the principle rather than a generic assertion of hard work.

Trade-offs and pitfalls
Over-rehearsed language that repeats the principle's name throughout a story tends to sound recited, and interviewers who run these loops regularly notice it quickly. Forcing one story into every principle bucket produces a worse answer than admitting a different story fits better and asking, where the format allows it, to use that one instead. Researching an outdated version of a company's list, then referencing a principle name that has since changed, undermines credibility even when the underlying story is strong.

Direct answer

Make the three explanations predict different, measurable fingerprints before looking at any data. First fix what "velocity" means (items finished per period, or cycle time per item), then split the problem into three non-overlapping parts: how much capacity there is, what the capacity is spent on, and how efficiently an item flows through stages. Technical debt (shortcuts in the code that make later changes slower), unclear requirements and process each leave a different mark on the flow stages.

Structured elaboration

Step 1: define and check the measurement. Story points (the relative size units a team gives each item) can drift (teams re-estimate) so I would use count of finished items and cycle time, the days from "started" to "done". Confirm the metric did not change definition.

Step 2: a MECE top split (mutually exclusive, collectively exhaustive).

• Capacity: headcount, attrition (people leaving), new joiners ramping (still learning, so not yet at full speed), time lost to meetings or on-call (the rotating duty to respond to production incidents).
• Work mix: share of effort on planned features vs bugs, incidents and unplanned work.
• Flow efficiency: how long an item takes per stage: clarify (requirements ready), build, review, test and release.

Step 3: map each suspect to a fingerprint.

The tree has three top-level branches. The three camps map onto them (debt into work mix and build time, requirements into the clarify stage, process into waiting between stages), and capacity is the branch none of the camps named, which is why the table has a fourth row.

Step 4: write predictions first, then sample. Take 40 completed items from each quarter, record time in each stage and flags (reopened, scope changed, touched module).

Worked example

Illustrative sample: median cycle time rose from 6 days to 10 days. By stage, days went: clarify 1 to 2, build 3 to 4, review 1 to 3, release 1 to 1. Check: 1 + 3 + 1 + 1 = 6 before and 2 + 4 + 3 + 1 = 10 after. Of the 4 extra days, 2 are review waiting (process), 1 is clarify (requirements) and 1 is build (possible debt). The finding is that no single camp is right: process explains about half and the other two roughly a quarter each. The next step is to check whether the build increase is concentrated in a few modules, which would separate debt from general slowdown.

Why a stage maps to a cause: review time is mostly an item waiting for a person, which is process. Clarify time is an item not being ready to start, which is requirements. Build time is the work itself, where debt would show, but only if it concentrates in particular modules, so the build day stays "possible debt" until that check. The other two top-level branches are measured differently. Capacity (illustrative): with 8 engineers, if 2 are new and work at about half speed while ramping, effective capacity is 6 + 2 x 0.5 = 7, which is 7 / 8 = 87.5% of full strength, 12.5% less. Work mix: count finished items by type. If unplanned work (bugs, incidents) grew from 15% to 30% of finished items, only 70% of the team's output is planned features instead of 85%.

Caveats on this illustrative sample. The stage list in Step 2 names five stages (clarify, build, review, test, release); the example above folds test time into review and release so that four stages sum to the cycle time. Also, stage medians do not in general add up to the median of total cycle time, so a real readout would compute the stage times per item and average or take medians of those. Finally, with 40 items per quarter a one-day shift in a stage can be inside normal spread, so the "about half" and "roughly a quarter each" split is a lead that sets the next check, not a verdict on the three camps; look at the spread (for example the 25th to 75th percentile range) for each stage before naming a winner.

Trade-offs and pitfalls

• Do not argue the three explanations in the abstract. Each camp can tell a plausible story, so the data must be framed to discriminate.
• Capacity and work mix are easy to forget and often explain a lot (a new hire ramp, more incident work).
• Sample, do not average everything. A hand-read sample of 40 items per quarter reveals reasons that dashboards hide.
• Avoid blame framing in the readout. Present stages, not teams.

Direct answer
This is a behavioral question best answered with a specific story showing you distinguished a genuine pattern from a one-off, kept the accountability conversation separate from the group postmortem, and led with coaching rather than punishment, while still being clear about the standard expected going forward.

Structured elaboration
A strong answer covers: the situation (what happened, why it warranted an accountability conversation rather than just the standard blameless process), how you determined it was a genuine pattern rather than bad luck, how you had the conversation itself (privately, focused on support and root cause rather than judgment), and the outcome, including how you protected the person's and the team's trust in future incident reporting.

Worked example
"An engineer on my team was involved in a second incident within two months, both traced to skipping the same pre-deploy verification step under time pressure. Before assuming it was negligence, I checked whether this was a genuine pattern: both incidents shared the same specific gap, so it was, rather than two unrelated issues that happened to involve the same person. I had a private conversation, not as part of the group postmortem, focused on understanding what was driving it. It turned out they'd been covering an unsustainable amount of on-call load for a teammate on leave and had started rushing to keep up. I addressed both sides: the workload issue got fixed by redistributing on-call coverage, which was the real systemic driver, and I paired them with a more experienced engineer on deploy discipline for a few weeks as direct support, framed clearly as investment in them, not punishment. Separately, the second incident's actual group postmortem stayed fully blameless and produced an automated pre-deploy gate that makes that specific step impossible to skip regardless of who's deploying, which is the fix that protects the whole team, not just this one person. Three months later there'd been no recurrence, and, just as important, the engineer's incident-reporting behavior stayed just as open as before, which told me the accountability conversation hadn't damaged their trust in the process."

Trade-offs and pitfalls
The most common weak answer either skips the distinction between pattern and coincidence (treating any second incident as automatic proof of a problem) or focuses entirely on the disciplinary angle without addressing what was actually driving the pattern, which misses the more senior insight that repeated mistakes are frequently a symptom of a systemic issue (workload, unclear process, inadequate training) rather than a character flaw.

Direct answer

Structure the middleware as a loop around the handler: an idempotency check runs first (before any retry bookkeeping, so a redelivery of an already-processed message never consumes a retry slot), then on each failure compute a capped exponential delay and sleep a random amount between zero and that cap (full jitter), and once the configured maximum retries is exceeded, push the message to a dead-letter queue (DLQ) and stop.

Structured elaboration

Where the idempotency check belongs. It runs before the retry loop, not inside it. A message redelivered after it already succeeded should short-circuit immediately, it should not be treated as attempt 1 of a fresh retry sequence, and it should not re-run the handler's side effects.

The retry loop. On each failure: if the attempt count exceeds maxRetries, escalate to the DLQ and stop; otherwise compute delay = min(maxDelayMs, baseMs * multiplier ** (attempt - 1)) and sleep a uniformly random value between 0 and that delay (full jitter) before the next attempt.

Configurable parameters. baseMs and multiplier control how fast the delay grows per attempt; maxDelayMs caps it so a message near its retry limit does not wait an unreasonably long time; maxRetries bounds total attempts before DLQ escalation.

function makeBackoffMiddleware({ baseMs, multiplier, maxRetries, maxDelayMs, rng, sendToDLQ, idempotencyCheck }) {
  return async function process(message, handler) {
    // Idempotency check runs BEFORE any retry bookkeeping: a redelivered
    // message already committed downstream short-circuits here instead of
    // consuming a retry slot or re-running side effects.
    if (await idempotencyCheck(message)) {
      return { status: 'skipped-duplicate', attempts: 0, delaysMs: [] };
    }

    let attempt = 0;
    const delaysMs = [];
    for (;;) {
      attempt += 1;
      try {
        await handler(message);
        return { status: 'processed', attempts: attempt, delaysMs };
      } catch (err) {
        if (attempt > maxRetries) {
          await sendToDLQ(message, err, attempt - 1);
          return { status: 'dlq', attempts: attempt - 1, delaysMs, error: err.message };
        }
        // Full jitter: sleep a UNIFORM random value between 0 and the capped
        // exponential delay, not the exponential value itself, this is what
        // prevents every instance that failed at the same moment from
        // retrying in lockstep (the thundering-herd failure mode).
        const capped = Math.min(maxDelayMs, baseMs * multiplier ** (attempt - 1));
        const jitterMs = Math.round(capped * rng());
        delaysMs.push(jitterMs);
        // production code awaits a real timer here: await sleep(jitterMs)
      }
    }
  };
}

Worked example

Executed with Node.js, baseMs = 100, multiplier = 2, maxRetries = 4, maxDelayMs = 5000, and a seeded pseudo-random number generator (mulberry32, seeded with 42) standing in for Math.random() purely so the printed jitter values are reproducible for this demo; production code would use Math.random() or crypto.randomInt() instead.

case1 (recovers within budget): {"status":"processed","attempts":4,"delaysMs":[60,90,341]}
case2 (exhausts retries -> DLQ): {"status":"dlq","attempts":4,"delaysMs":[67,35,211,219],"error":"downstream-500"}
dlq contents: [{"id":"evt-2","attempts":4,"error":"downstream-500"}]
case3 (duplicate redelivery skipped): {"status":"skipped-duplicate","attempts":0,"delaysMs":[]}

Case 1: a handler that fails 3 times then succeeds recovers on attempt 4, within the 4-retry budget, with 3 recorded jitter delays (one per failure before the successful attempt). Case 2: a handler that always fails exhausts all 4 retries and escalates to the DLQ, with the DLQ entry recording the event id, attempt count, and error. Case 3: redelivering the same event id from case 1 (already committed) is caught by the idempotency check and returns immediately with zero attempts, confirming the check runs ahead of the retry loop rather than inside it.

Trade-offs and pitfalls

Complexity. O(1) work per attempt (one comparison, one exponentiation, one random draw); total attempts bounded by maxRetries + 1, so worst-case work per message is O(maxRetries).

Edge cases.

• A message redelivered mid-retry (a second copy of the same event arrives while the first copy's retry loop is still running) needs the idempotency check to be safe under concurrency too, a check-then-act pattern here has the same race risk as any other idempotency check, it needs an atomic claim, not just a lookup.

• If handler itself is not safe to partially re-run (it has non-idempotent side effects), retrying at all is unsafe regardless of how well the backoff is tuned, the retry middleware assumes the handler's work is safe to repeat.

• A cap (maxDelayMs) that is too low relative to how long the downstream outage actually lasts causes retries to keep hammering a still-down dependency at the capped rate instead of backing off further.

• Sleeping the exponential value itself instead of a random value up to it (no jitter at all) reintroduces the thundering-herd risk this design exists to avoid.

• Forgetting to insert the idempotency check ahead of the retry loop (instead of, say, only checking once right before the DLQ push) lets an already-succeeded message consume retry attempts and, worse, potentially re-run a non-idempotent handler on every redelivery.

Direct answer

When two senior stakeholders give you contradictory direction on the same decision and both expect you to follow theirs, the right first move is not to pick a side or quietly satisfy whichever one you last spoke to, but to make the contradiction visible to both of them together and force an explicit resolution before proceeding.

Structured elaboration

1. Don't silently choose. Picking one direction without surfacing the conflict either burns the relationship with whoever you didn't follow, or produces work that gets undone when the conflict eventually surfaces anyway, at a later, more expensive point.
2. Bring the contradiction to both of them together, factually. A short message or meeting stating plainly "I've received direction X from one of you and direction Y from the other, and I need clarity on which to follow before proceeding" reframes the problem as theirs to resolve, not yours to guess at.
3. Provide the trade-off, not just the conflict. Where possible, lay out what each direction implies (cost, timeline, risk) so the conversation between them is grounded in consequences, not just preference.
4. If they can't resolve it between themselves, escalate to whoever can. A genuine stalemate between two people with equal standing over you needs a tie-breaker above both of them; naming that clearly rather than continuing to sit in the middle is the responsible move once direct resolution has been tried and failed.
5. Document the resolution. Once a direction is confirmed, write it down and share it back to both, so the same conflict doesn't quietly resurface a month later as a "misunderstanding."

Worked example

Two regional teams each push a different prioritized roadmap for the same shared platform, both expecting their preference to be honored. Rather than picking one, laying out both roadmaps side by side with their business rationale and cost of NOT doing the other, presented jointly to both regional leads, forces a real conversation about trade-offs between people who actually have standing to make that call, instead of an individual contributor guessing at organizational priorities they don't own.

Trade-offs and pitfalls

Surfacing the conflict too quickly, before doing any homework on the trade-offs, can look like you're avoiding the work of even a preliminary recommendation; where you have a well-reasoned view, offering it as input to their conversation (not as a decision you're making for them) is usually stronger than presenting a bare, unexamined conflict.

Direct answer. Replace the flat parameter list with a small, named data structure (a dataclass, struct, or builder) that groups related fields and gives optional ones real defaults -- this shrinks call sites, kills positional-order bugs, and lets you evolve the shape without touching every caller's signature.

The problem with 8 positional parameters

processOrder(int id, String email, double discount, boolean priority,
             Date shipDate, Address bill, Address ship, String notes)

• Two adjacent Address parameters are a classic transposition hazard: swap bill and ship and the compiler says nothing.
• A caller who only needs to set priority still has to know and supply all eight values in the right order.
• Adding a ninth parameter means editing every call site, even ones that don't care about it.

Refactor (Python, but the shape generalizes to any language with structs/records)

from dataclasses import dataclass
from datetime import date

@dataclass
class OrderRequest:
    order_id: int
    customer_email: str
    ship_date: date
    billing_address: str
    shipping_address: str
    discount_pct: float = 0.0
    is_priority: bool = False
    notes: str = ""

def process_order(req: OrderRequest) -> dict:
    return {"id": req.order_id, "email": req.customer_email, "discount": req.discount_pct,
            "priority": req.is_priority, "ship_date": req.ship_date,
            "bill_addr": req.billing_address, "ship_addr": req.shipping_address, "notes": req.notes}

Verified equivalent output against the original 8-argument call, and a caller who only needs the required fields can now write OrderRequest(2, "b@x.com", date(2026,1,2), "1 Rd", "1 Rd") instead of supplying all eight positionally.

What this buys you

• Named fields at the CALL SITE (OrderRequest(order_id=2, ...) or keyword construction) make transposition errors a compile-time or immediately-visible mistake instead of a silent bug.
• Optional fields get real defaults, so most callers write a shorter, more honest call.
• Adding a new field is a one-line change to the dataclass; existing callers that don't set it are unaffected.

Trade-offs and pitfalls

• A parameter object can become a dumping ground if you keep adding unrelated fields to it -- if two groups of fields never change together, that's itself a signal the object should split into two.
• In languages without a lightweight struct/record type, a builder pattern is the usual alternative when you also need staged/optional construction with validation.
• Don't reach for a parameter object at 3-4 parameters if they're all tightly related and always used together (e.g., x, y, z coordinates) -- the smell is specifically MANY parameters, several of them optional or same-typed, not parameter count in the abstract.

Direct answer

Numbers tell people what happened; a narrative tells them why it matters and to whom. When a data table or a business case document isn't landing, building the argument as a short story, real people, a specific conflict, stakes tied to something they already care about, anchored by evidence rather than replaced by it, can move a decision that pure data couldn't.

Structured elaboration

How this differs from the two other evidence vehicles. This is not the same move as anchoring a case in the data-table or business-case artifact (the default, and often the right choice when the audience trusts numbers on their own). It's also not the same as letting the physical prototype artifact carry the argument by itself (the approach where the thing you built does the persuading). Here the vehicle is a narrative: a sequence with a protagonist, a conflict, and stakes, with evidence anchoring the story rather than the story decorating the evidence.

Building the narrative.

1. Pick a protagonist who is actually affected by the status quo: a user, a support rep, an engineer on call. Not an abstraction.
2. Establish the conflict: what specifically goes wrong for them today, and why it keeps happening.
3. Anchor with evidence: one or two credible data points and a direct quote, not a full dashboard. The story should feel evidenced, not decorated.
4. Build to a concrete ask: a decision or, better, a small experiment, not just "please feel differently about this."

Adapting the telling by audience.

Worked example

Situation: a product org was deadlocked between funding a flashy AI onboarding feature leadership was excited about, and fixing a plain, unglamorous signup flow that was quietly losing new users.

The narrative: a short story following one new user through the existing signup flow, where she gets stuck partway through and gives up, alongside a support rep who fields the same complaint on repeat. The conflict: leadership wanted to invest in something exciting while the thing actually costing the company users was mundane. The stakes: continuing to ship novelty without fixing the leak meant the AI feature would land on a shrinking base.

Anchoring the story: a couple of real interview quotes from users who abandoned partway through, paired with the observed drop-off point in the flow, kept the story honest rather than invented.

Adapting the telling: for engineering, the story led with exactly where in the flow users got stuck and why. For product, it led with the user's journey and what the AI feature would cost in opportunity if the base kept shrinking. For the executive review, the ask came first: "approve a two-week experiment on the signup flow before committing the quarter to either option," with the story as the two-minute follow-up, not the opener.

Resolution: instead of the roadmap fight resolving by whoever argued loudest, leadership agreed to run the signup experiment first and revisit the AI feature with better information afterward. The story didn't replace the case for prioritization: it gave the room a shared, human reason to care about a decision that had been sitting in the abstract.

Trade-offs & pitfalls

• A narrative without real evidence anchoring it reads as manipulation, not persuasion, especially to an audience that already leans skeptical of "storytelling" in a business context.
• Over-tailoring the same story so heavily per audience risks contradicting yourself if two audiences compare notes; the underlying facts should stay identical even as the framing shifts.
• Narrative takes longer to build well than a table of numbers. It's worth the investment when the decision is stuck on people not caring yet, not when it's stuck on people not believing the numbers.
• Leading with story instead of the ask in front of executives is a common miscalibration; senior communicators state the ask first and let the narrative support it, not the reverse.

Direct answer

Recommend PostgreSQL, using JSONB columns (a binary JSON column type that stays queryable and indexable) for the flexible fields, over MongoDB for this specific combination of requirements, because "occasional complex joins" and "multi-entity transactions" are exactly PostgreSQL's strengths and MongoDB's comparative weak points, while PostgreSQL's JSONB support gives most of the schema flexibility the question is asking for almost for free. That recommendation flips if the flexible fields genuinely dominate the workload (most fields are dynamic, joins and multi-entity transactions are rare, and the system needs to scale writes horizontally past what a single PostgreSQL primary can absorb), in which case MongoDB becomes the better default.

Structured elaboration

Why the two named requirements favor PostgreSQL specifically. MongoDB has supported multi-document ACID transactions since version 4.0, extended across sharded clusters since 4.2, so "MongoDB cannot do transactions" is an outdated objection. The real, current gap is cost and capability, not existence: a multi-document transaction in MongoDB is a heavier, more deliberately-invoked operation than PostgreSQL's native, always-on transactional model, and MongoDB's join mechanism (the $lookup aggregation stage) is meaningfully less capable and less performant than a relational query planner's native multi-way join, especially once more than two collections are involved. For a workload where joins and multi-entity transactions are a stated, real requirement, even an "occasional" one, PostgreSQL is answering the requirement natively where MongoDB is answering it through a heavier mechanism.

Where JSONB gets you most of MongoDB's advantage without giving up the relational strengths. A JSONB column holds a schemaless document inside an otherwise ordinary relational table row. It can be indexed (commonly with a Generalized Inverted Index, GIN, which supports efficient containment and key-existence queries against the JSON structure) and queried with operators for containment, path extraction, and key lookup, all inside standard SQL, alongside standard columns and standard joins to other tables. The result is a table that behaves relationally where the data is relational, and flexibly where it is not, in the same row.

Evaluation criteria, both directions.

Migration plan, PostgreSQL direction (the recommended default here). Identify the genuinely relational entities (users, orders, whatever has real foreign-key relationships and needs real joins) and normalize those into standard tables. Put the dynamic, variable-shaped attributes into a JSONB column on the relevant table, rather than either a wide sparse table or an entity-attribute-value pattern. Add a GIN index on the JSONB column scoped to the actual query patterns the application uses against it (containment queries need a different index configuration than path-based lookups; verify which the application needs before indexing broadly).

Migration plan, MongoDB direction (if the flip condition applies). Even though the schema is intentionally flexible, define an explicit schema-validation ruleset (MongoDB's $jsonSchema validator) rather than leaving every collection fully unconstrained; an unconstrained flexible schema drifts silently over time as different code paths write slightly different shapes, and the validator catches that drift at write time instead of letting it surface later as an application bug.

Two worked scenarios that both look "flexible-schema" but land on different sides of the recommendation.

Evolving-schema documents (for example, a product catalog where attributes vary wildly by category and change often). This is the strongest case for a document-shaped model: catalog items rarely need multi-entity transactions (updating one product's attributes is a self-contained operation), and cross-category joins are rare by nature (a shoe's size chart has nothing to join against a book's page count). If a catalog service is the entire system, MongoDB, or PostgreSQL with JSONB and no meaningful relational structure at all, are close to equivalent; PostgreSQL with JSONB still edges ahead if the catalog needs to join to inventory, pricing, or supplier tables elsewhere in the same system, which most real catalogs eventually do.

ML model metadata (hyperparameters, evaluation metrics that vary by model type, training lineage). This looks equally flexible-schema at first glance, hyperparameters and metrics genuinely vary by model type, but it is actually a strong case FOR PostgreSQL, not against it, because the metadata almost never stands alone: it needs to join back to a dataset table, an experiment table, and a user or team table, and the single most important operation on this data, atomically flipping which model version is flagged "production" while un-flagging the previous one, is a transactional, joined, all-or-nothing operation by nature. Storing the variable hyperparameter and metric fields in a JSONB column on an otherwise normal, foreign-keyed model_versions table gets the schema flexibility this scenario needs while keeping the transactional swap and the joins to dataset and experiment tables fully native.

Worked example

The concrete case for choosing between PostgreSQL and MongoDB rarely comes down to which one can store flexible data (both can); it comes down to what the actual query and transaction pattern costs on each. Frame the "production model swap" operation from the ML-metadata scenario explicitly as SQL to make the transactional requirement concrete:

-- atomic production-model swap, the transactional
-- operation that makes this a PostgreSQL-favoring scenario despite the flexible metadata.
BEGIN;

UPDATE model_versions
SET is_production = false
WHERE model_id = 'checkout-fraud-classifier'
  AND is_production = true;

UPDATE model_versions
SET is_production = true
WHERE model_id = 'checkout-fraud-classifier'
  AND version = 'v14';

-- hyperparameters and metrics live in a JSONB column on the same row:
--   metadata @> '{"framework": "xgboost"}'   -- containment query, uses a GIN index
--   metadata -> 'eval_metrics' ->> 'auc'     -- path extraction for a single metric

COMMIT;

Both updates inside this single transaction succeed together or fail together, so it is never possible for two model versions (or zero) to be simultaneously flagged production, a correctness property this scenario genuinely needs. The commented containment and path-extraction queries show the JSONB column answering the "flexible metadata" half of the requirement in the same table, with the same transaction boundary, and the same standard SQL connection any BI or migration tool already speaks.

Trade-offs & pitfalls

• Treating "MongoDB doesn't support transactions" as still true. It has since version 4.0 (single-shard) and 4.2 (across shards); the real, current gap is relative cost and capability versus PostgreSQL's native transactional model, not existence.
• Assuming a flexible-schema scenario automatically favors a document database. The ML-metadata scenario looks flexible-schema on the surface and is actually a strong relational case, once the join and atomic-swap requirements are considered; check the actual operations the data needs, not just its shape.
• Leaving a MongoDB collection's schema completely unvalidated "because it's flexible." Without a validator, schema drift accumulates silently across different code paths and surfaces later as a confusing application bug, not a database error.
• Over-normalizing the JSONB fields into rigid columns "for consistency." That defeats the reason to use JSONB in the first place; keep genuinely dynamic, sparse, or per-category-varying fields in the JSONB column and normalize only what is truly common and stable across every row.
• Indexing a JSONB column generically without checking the actual query pattern. A GIN index tuned for containment queries does not necessarily serve path-based extraction queries efficiently; match the index configuration to how the application actually queries the column.

Direct answer

The transactional outbox pattern gets atomicity between a local database update and publishing an event by writing the event as a plain row in the SAME database transaction as the business change, instead of trying to atomically commit across two separate systems (the database and the message broker). A separate background publisher then reads that outbox table and delivers the events, so the hard part of the problem (getting a message onto a broker) is pushed into an at-least-once delivery loop the consumer can absorb, rather than solved by a distributed commit protocol.

Why not just use a distributed transaction directly

A two-phase commit (2PC) across the database and the broker would need the broker to act as a participant in the same commit protocol as the database: it would have to accept a "prepare" call, hold the message uncommitted, and only make it visible once a coordinator later sends "commit". Kafka's and SQS's client APIs do not expose that kind of prepare/commit participant interface (Kafka has its own separate transactional-producer API, not an XA participant interface, XA being the X/Open standard for coordinating a transaction manager with multiple resource managers), so 2PC across a database and a managed broker directly is not something you can wire up against most production message buses. Even where a broker does support it, the coordinator becomes a blocking point: each participant holds its local lock from "prepare" until it hears back, so a coordinator crash between phases can leave a participant blocked indefinitely.

Outbox table schema

Writing the event

Inside the same database transaction that updates the business tables (e.g. orders), the application also inserts a row into outbox. Both inserts commit together or not at all, so there is no window where the business change exists without a corresponding outbox row, or vice versa.

Background publisher

A worker process polls with something like SELECT * FROM outbox WHERE status = 'pending' ORDER BY id FOR UPDATE SKIP LOCKED LIMIT 100. FOR UPDATE SKIP LOCKED lets multiple publisher instances run concurrently without two of them claiming the same row: each instance simply skips rows another instance already has locked. The worker publishes each claimed row to the broker, and only after the broker acknowledges does it mark the row sent. As an alternative to polling, a change-data-capture (CDC) tool such as Debezium can tail the database's write-ahead log (WAL, the durability log the database already writes before committing) and stream outbox inserts to the broker with lower latency and no polling interval, without any application code change.

Avoiding duplicates and lost events across a crash

Trace through a concrete run for outbox row id=482:

1. Application transaction commits: orders row and outbox row id=482 (status=pending) both durable together.
2. Publisher polls, claims row 482 via SELECT ... FOR UPDATE SKIP LOCKED.
3. Publisher sends row 482's payload to the broker; broker acknowledges receipt.
4. Publisher crashes before executing UPDATE outbox SET status='sent' WHERE id=482.
5. Publisher restarts, polls again; row 482 is still status='pending', so it gets re-claimed and re-published. The broker now has two copies of the same event.
6. Because row 482's id travels with the payload as a dedup key, the consumer (or the broker's own dedup mechanism) recognizes the second delivery as a repeat and drops or no-ops it.

If the crash instead happens before step 3 (before the publish call), nothing has reached the broker at all: row 482 simply stays pending and gets picked up on the next poll, with no data loss. The pattern never produces a business change with a missing event, only occasional duplicate deliveries, which is why the consumer side still needs to be idempotent or dedup-aware; the outbox guarantees "at least once", not "exactly once", on its own.

sequenceDiagram
    participant App
    participant DB as Database
    participant Pub as Publisher
    participant Bus as Message Bus
    App->>DB: BEGIN TXN
    App->>DB: INSERT orders row
    App->>DB: INSERT outbox row (pending)
    App->>DB: COMMIT
    Pub->>DB: SELECT pending FOR UPDATE SKIP LOCKED
    DB-->>Pub: outbox row id=482
    Pub->>Bus: publish(id=482)
    Bus-->>Pub: ack
    Pub->>DB: UPDATE outbox SET status=sent WHERE id=482

Production checklist

• Alert on outbox backlog depth (rows still pending beyond an expected age), not just publisher liveness, since a stuck publisher looks alive but stops draining the table.
• Retention job to delete or archive sent rows so the table doesn't grow unbounded.
• Partition/order guarantee: publish using aggregate_id as the broker partition key so events about the same entity are delivered in the order they were written.
• Version the payload schema so a newer producer and an older consumer can coexist during a rollout.

Trade-offs & pitfalls

Outbox trades immediate, synchronous cross-system consistency for simple local atomicity plus eventual, at-least-once delivery: the business transaction commits instantly (no waiting on the broker), but there is a real (if usually short) window between the commit and the event actually reaching the broker. A common mistake is treating "broker acknowledged" as "consumer processed": the outbox only guarantees the event left the outbox table, not that the ultimate side effect happened, so end-to-end correctness still depends on consumer idempotency. Another common mistake is forgetting to key on aggregate_id for ordering, or running multiple publisher instances without SKIP LOCKED-style claiming, which produces either out-of-order delivery or duplicate publishes from two workers claiming the same row simultaneously.