Airbnb Solutions Architect Interview Preparation Guide - Mid Level

Non-functional requirements (NFRs) describe how a system must behave — constraints and quality attributes (performance, reliability, security, scalability, compliance) that support functional requirements. They’re expressed as measurable acceptance criteria so architects and engineers can validate the solution.

Examples and measurable acceptance criteria for a high-traffic e-commerce platform:

• Performance: 95th-percentile page load time for product and checkout pages ≤ 1.5s under peak load of 200k concurrent users. End-to-end checkout latency ≤ 2s.
• Availability: Monthly uptime ≥ 99.95% (≤ 21.9 minutes downtime/month) measured per production region with automated health checks and failover.
• Security: No critical OWASP Top 10 findings in production scans; all payment data encrypted at rest (AES-256) and in transit (TLS1.3); quarterly penetration test with remediation SLA ≤ 30 days for high-risk findings.
• Scalability: System auto-scales to handle a 5x baseline traffic surge within 3 minutes while keeping error rate < 0.5% and maintaining performance SLA.
• Compliance: PCI-DSS level 1 controls in place for payment flows; annual external audit with zero major non-conformities; data retention and deletion policies enforce GDPR right-to-be-forgotten within 30 days.

These criteria map directly to architecture decisions (CDN, autoscaling, multi-AZ deployment, WAF, encryption, monitoring, audit processes) and allow objective validation during design and acceptance.

Pub/sub vs point-to-point: Pub/sub decouples producers and consumers via topics — publishers emit messages to a broker which fans out to zero or many subscribers (one-to-many). Point-to-point (queue) delivers each message to a single consumer (one-to-one) guaranteeing consumer-exclusive processing.

When I’d specify brokered pub/sub vs direct peer-to-peer:

• Brokered pub/sub: choose this when you need loose coupling, multicast delivery, durable subscriptions, replay, cross-language integration, or dynamic consumer membership (e.g., telemetry streams, notifications, event-driven microservices). A broker (Kafka, RabbitMQ, NATS, PubNub) simplifies routing, persistence, auth, and monitoring.
• Direct peer-to-peer: choose this for low-latency, ephemeral connections between known endpoints where you control connectivity (e.g., real-time multiplayer game mesh, browser-to-browser WebRTC for small groups) to avoid broker hops and cost.

Scalability and operational implications of brokered approach:

• Scalability: brokers enable horizontal scale (partitioning/topics, consumer groups) and efficient fan-out; they can buffer bursts and smooth producers/consumers. But design must account for partitioning strategy, throughput limits, and consumer lag.
• Ops: brokers centralize complexity — you must run, monitor, secure, and capacity-plan them (disk, network, retention). Single point of failure risk unless clustered. Upgrades and schema evolution require governance. Observability (metrics, tracing), quota controls, and cost (managed vs self-hosted) influence choice.
  Trade-off: brokered systems buy developer productivity and reliability at the cost of operational overhead and potential added latency; use peer-to-peer only when low latency and minimal operational surface trump the benefits of decoupling.

Requirements & constraints:

• Strong linearizability (writes must be ordered and visible immediately).
• Majority quorum for safety.
• Minimize write latency for US users concentrated in A and B.
• Inter-region latencies: A–B 20ms (fast), A–C 200ms, B–C 220ms (slow).

Recommended designs (two practical options with trade-offs):

Option 1 — Latency‑optimized, US-majority (preferred for UX):

• Replica placement: 3 voting replicas — A1 and A2 both in region A, B1 in region B. Place region C as a non-voting (read-only / async) replica for DR/backups.
• Quorum: N=3, majority=2. Write quorum W=2, Read quorum R=2 (or leader reads).
• Leader: run leader in A (or sticky leader to nearest client).
• Behavior: A client in A or B writes to leader in A; leader replicates to A2 and/or B1. As soon as two voting replicas ack (usually A1+A2 or A1+B1), write is committed. Because A–B is 20ms, most writes complete within ~20–40ms RTT + processing; C is not on the fast path, so its ~200ms latency doesn't hurt write latency.

Why this is linearizable:

• Majority acks ensure a single committed order. Leader ensures serialization; reads from leader or requiring majority preserve linearizability.

Trade-offs:

• If region A fails entirely, majority may still be available if B1 plus a surviving A replica exist — but if both A replicas fail, you lose majority (availability risk). To mitigate, run the two A replicas on distinct AZs/racks.
• C is not a voter, so geographic durability to C is asynchronous — possible data loss if A/B fail before async catches up.
• Small voting set reduces tolerance to node failures (loses availability with two simultaneous failures).

Option 2 — Geo‑durable, balanced safety (stronger durability, higher latency):

• Replica placement: 5 voting replicas — A1,A2 in A; B1,B2 in B; C1 in region C.
• Quorum: N=5, majority=3. W=3 for writes.
• Leader: prefer US leader (A) to minimize client->leader RTT, but commit requires 3 acks. In practice commits will often use two local + one across A–B (20ms) or A–B–C (C adds 200ms).
• Behavior: If leader in A, typical fast path would be A1 + B1 + A2/B2 combination; write latency ≈ RTT to B (20ms) plus local processing — higher than Option 1 but maintains durability if either A or B loses a node.

Trade-offs:

• Higher write latency (third ack often requires crossing regions if local replicas insufficient).
• Better tolerance to failures: can survive multiple node failures as long as majority remains.
• More operational cost and complexity.

Additional strategies & considerations:

• Voting vs non-voting: Use non-voting replicas (learners) in high-latency regions (C) for backups/analytics to avoid slowing writes.
• Leader affinity: Keep leader in the US and implement sticky leader + local read optimization (leader reads locally) to reduce observed latency.
• Quorum placement heuristics: Ensure majority can be formed within US under normal failure scenarios by placing an odd number of voters mostly in A/B.
• Failure modes & monitoring: Monitor inter-region links and implement failover policies. For Option 1, prepare automated promotion of a B replica to voter in emergencies.
• Consistency/read patterns: If many reads originate in US, use leader reads or read-from-majority with stale-read avoidance to retain linearizability.
• Safety vs liveness trade-off: Favoring US-majority optimizes latency but weakens durability to remote region loss; adding remote voters increases durability but also latency.

Recommendation:
If primary goal is minimizing perceived write latency for A/B users while still guaranteeing linearizability for production workloads, choose Option 1: 3 voting replicas concentrated in US (A,A,B) with C as an async replica. For customers with strict geo-durability/regulatory needs, adopt Option 2 (5 voters) or hybrid: 3 US voters + 1 remote voter + one non-voter and accept higher write latency.

Clarify requirements: payouts must be correct, auditable, real-time/near-real-time for drivers, and transparent to customers. Design around a single canonical payout engine that composes components (base fare, distance/time, surge multiplier, incentive bonuses, promotions/discounts) with strict precedence and idempotency.

Telemetry to capture:

• Immutable event stream per trip: request_created, driver_assigned, trip_start, trip_end, fare_estimate, surge_applied, promo_applied, reprice_event, payout_calculated, payout_settled, dispute.
• Context: timestamps, location polygons, price IDs (surge zone id, promo id), driver and customer IDs, immutable fare snapshot.
• Metrics: counts, latency, failure rates, and reconciliation deltas.

Canonical payout pipeline:

1. Ingest immutable trip event stream into payout service.
2. Normalize components (base fare, distances).
3. Apply surge: lookup surge policy by zone+time → produce surge_multiplier and surge_id.
4. Apply incentives: incentive rules engine (goal-based, per-trip, guaranteed) produces bonus_amount and incentive_id, using same fare snapshot.
5. Apply promotions/discounts to customer side (affects net revenue but not driver bonus unless rule specifies).
6. Compose final driver_payout = base_components * surge_multiplier + eligible bonuses − driver_fees.
7. Persist ledger entry (immutable), produce audit record and reconciliation job.

UI messaging requirements:

• Driver app: show estimated payout with breakdown (base, surge multiplier, bonus name/amount, IDs) before accept if applicable; on completion show final payout with same breakdown and “why changed” if re-pricing.
• Rider app: show fare estimate with surge indicator and promo applied; on charge show final receipt and clarify driver payout only if policy requires.
• Notifications: clear language when incentives are conditional (e.g., “Complete 3 trips in X to earn $Y”).

Edge cases & handling:

• Overlapping promotions/incentives: enforce deterministic precedence (e.g., customer promos never reduce driver guaranteed minimum unless explicit) and represent combined rule outcome with IDs; rules engine must reject ambiguous rules.
• Mid-trip re-pricing: record reprice_event with old and new snapshots; driver payout uses rule (choose either snapshot_at_start OR snapshot_at_end OR blended) defined per product; show driver the rule up-front.
• Idempotency & retries: use event IDs and ledger dedupe keys.
• Disputes & retroactive adjustments: create adjustment transactions linked to original ledger row; keep original immutable for audit.
• Offline/late events: allow compensating transactions flagged and visible.

Scalability & governance:

• Rules engine with versioning; feature-flag deployments; AB testing supported.
• Reconciliation batch + real-time monitoring; daily audits comparing ledger -> payments processor.
  This design ensures a single source of truth, clear UI transparency, and safe handling of complex overlaps.

Direct answer

Keep a single, easy-to-find decision log tied directly to the work it affects: what was decided, the options considered, the reasoning, and who owns it, updated by whoever is making the decision at the moment it is made, not reconstructed later from memory.

Structured elaboration

What belongs in an entry

A short, consistent structure works better than a long one, because people will actually fill it out: a title, the date, who owns it, the context in one or two sentences, the options considered with their trade-offs, the decision itself, and the reasoning behind it in a few bullet points.

Where it lives

The log needs to be one discoverable place, linked from the tickets, docs, or roadmap items it affects, not scattered across meeting notes and chat threads. A shared doc or wiki page with a simple table works; the tool matters less than the discipline of always linking to it.

Who keeps it current

The person who owns the decision, not a rotating scribe with no stake in it, writes or finalizes the entry, ideally right after the decision is made, while the reasoning is still fresh and easy to state accurately.

How it gets used afterward

In retrospectives, revisit decisions that affected the outcome and check whether the original assumptions held. For onboarding, a short list of the most consequential recent decisions gives a new team member the context that would otherwise take weeks of osmosis to pick up.

Worked example

A team is deciding between two ways to notify users of an event: a push notification versus an in-app banner. The entry, once decided, looks like this: title, "Notification channel for event alerts"; date and owner, the decision owner's name and the date; context, users were missing time-sensitive alerts under the current in-app-only approach; options considered, push notification (faster delivery, requires a new permission prompt), in-app banner only (no new permission needed, slower to be seen), and both channels (best coverage, more engineering and support surface); decision, push notification with an in-app banner as a fallback for users who decline the permission; reasoning, the delay in the in-app-only approach was the specific problem being solved, and the fallback covers users who opt out.

Anyone who later asks why the team does not just use an in-app banner, since it is simpler, can read this entry and see the trade-off was already considered, rather than re-litigating it from scratch.

Trade-offs and pitfalls

A log nobody updates is worse than no log: it creates false confidence that the reasoning is captured somewhere, while actually going stale. The fix is keeping entries short enough that updating one takes minutes, rather than requiring a formal write-up every time.

A log can also be used as a weapon later, such as insisting a past decision still holds in a situation where circumstances genuinely changed and revisiting was the right call. The log should record reasoning, not lock in a decision forever; a review date or a note on when to re-evaluate keeps it a living reference instead of a trap.

Goal: ensure customer-driven requirements inform the product roadmap while keeping SAs focused on deep design work and avoiding frequent context switches.

Coordination structures

• SA Liaisons: assign 1 SA as primary liaison to 1–3 squads (rotating 8–12 week assignments). Liaison attends sprint planning & PI planning as needed, owns technical backlog grooming for that squad.
• SA Advisory Council: monthly cross-functional forum (SAs, PMs, Eng Leads, Sales Ops) to surface strategic customer needs, prioritize architectural investments, and resolve trade-offs.
• Escalation rota: single-threaded intake for urgent customer asks routed to on-call SA.

Lightweight artifacts

• Customer Impact Brief (1 page): problem, customer segment, success metrics, constraints, urgency. Template fields to standardize intake.
• Architectural Intent Card (one-pager): proposed high-level solution, dependencies, estimated SA effort (T-shirt), risks, migration plan.
• Tagged Jira fields: customer_priority, sa_effort, architectural_type to filter work and generate reports.

Rules to protect SA capacity

• Capacity reservation: allocate 20–30% of SA time for sales/support & ad-hoc reviews; remaining time reserved for roadmap/architectural work and deep dives.
• No ad-hoc meetings rule: all new requests go through intake form; ad-hoc meetings require approval and must be scheduled in reserved slots (office hours).
• Time-boxed design reviews: max 60 minutes for initial triage; follow-ups scheduled as focused deep-dive sessions.
• SLA for intake: initial response within 48 business hours; advisory council decision within 10 business days for non-urgent items.

Process flow

1. Sales/customer fills Customer Impact Brief → triage by SA liaison within SLA.
2. If strategic, council discusses and assigns Architectural Intent Card and SA effort.
3. PM incorporates outcome into roadmap with clear dependencies and timeline; SA liaison supports implementation with scoped deliverables.

Metrics and guardrails

• Track number of context switches per SA/week, % time on deep design, intake-to-decision time, roadmap items influenced by customer briefs.
• Quarterly review to adjust capacity %, rotation length, and intake templates.

Example: reserve 25% SA capacity, liaison rotates every 10 weeks, council meets first Monday monthly — this reduced ad-hoc interruptions by ~40% and increased documented customer-driven roadmap items by 2x in pilots.

Clarifying assumption: the DB stores append-only time-series logs with heavy time-range queries (recent windows, historical scans), needs TTL/compaction/archival, and must scale to billions of rows across many nodes.

Summary recommendation: range-based sharding by time (or hybrid time + tenant) generally better supports time-range queries and TTL/compaction; hash-sharding gives uniform load but complicates time-aware operations.

Comparison:

• Time-range queries

  • Range sharding: Excellent. Consecutive timestamps colocated so queries hit few shards, low fanout and predictable latency.
  • Hash sharding: Poor for ranges — a time window is spread across many nodes, high fanout and aggregation cost.

• Compaction / TTL

  • Range sharding: Simple and efficient. Whole segment files or partitions can be compacted or dropped by time boundary with minimal IO; fast GC.
  • Hash sharding: TTL requires coordinated deletes across many nodes; compaction benefits reduced because time-coherent data is fragmented.

• Rebalancing costs

  • Range sharding: Rebalancing when adding capacity can be efficient if partitioned (move whole time-partitions). But hot partitions (recent time) can create skew and require splitting.
  • Hash sharding: Even distribution reduces hot spots; adding nodes requires moving hashed ranges (consistent hashing reduces movement to ~1/N of data) but moves many small pieces; operational complexity higher but less single-partition hotness.

• TTL / archival interaction

  • Range sharding: Archive by copying/detaching entire files/partitions (cheap, consistent). TTL eviction can be implemented by dropping partitions and updating metadata.
  • Hash sharding: Archival needs coordinated scan/transfer across nodes; incremental checkpoints required to ensure consistency.

Trade-offs & mitigations:

• Hybrid: Hash within fixed time buckets (time-based partitioning first, then hash for intra-partition balance) gives low-fanout queries and good distribution.
• Use rolling time-partitions (daily/hourly) to limit partition sizes and simplify rebalancing/archival.
• For write-hot recent data, use write-optimized nodes (or hot tier) and migrate older partitions to cold storage.

Conclusion: For a logging time-series DB prioritizing time-range queries and efficient TTL/archival, prefer range/time-based partitioning possibly combined with intra-partition hashing to balance load and control rebalancing costs.

Direct answer

Score each non-functional requirement (NFR, a quality attribute like security, maintainability, or observability rather than a feature) by the risk of skipping it, not by how important it sounds in the abstract, then fund the highest-scoring ones first and consciously document what you are deferring. In this scenario that usually means security and enough observability to see when something breaks get funded first, while maintainability work (broad refactors, exhaustive test coverage) is the one to accept debt on, because a small team can still move fast without it in the short term, while an invisible security or reliability gap can end the project.

Structured elaboration

A repeatable scoring rule

Score each candidate NFR on impact, likelihood, and effort:

$$\text{risk score} = \frac{\text{impact} \times \text{likelihood}}{\text{effort}}$$

where impact and likelihood are rated on a small scale, say 1 to 5 (illustrative severity ratings calibrated with the team) and effort is the cost to address it now. Rank by score, fund top-down until the budget runs out, and document what falls below the line and why.

Worked example (the three from the question)

Assume illustrative ratings for a client project on a tight timeline:

By this scoring, observability actually ranks first here, cheap and high odds you'll need it fast when something breaks. Security ranks second, highest impact and worth the extra effort. Maintainability ranks last, which is the one to consciously under-invest in: ship with a thinner test suite and postpone larger refactors, but only after writing down that decision so it is a choice, not an accident.

Defending the deferred one

Under-investing in maintainability is defensible specifically because its failure mode is slow (code gets harder to change over months) rather than sudden (unlike a security breach or a blind outage), and because a small team on a tight timeline has not yet hit the coordination cost that makes poor maintainability expensive. Conway's Law (a system's structure tends to mirror the communication structure of the team that built it) means that cost shows up later, once more people touch the same code, which is exactly when the decision should be revisited.

Extension (absorbed angle): the same rubric on six NFRs under a revenue constraint

Given six candidate NFRs for a new API (availability, latency, security, observability, maintainability, scalability) and a fixed budget, weight impact by revenue at risk instead of a generic scale, then rank the same way:

The mechanics are identical to the three-NFR case: rank by risk per unit of effort, fund down the list, write down what was deferred and why.

Trade-offs & pitfalls

• Pitfall: treating this as "pick two of three" instead of a continuous funding line; you can partially fund all three (a minimal security baseline plus basic dashboards plus a lighter test suite) rather than fully skipping one.
• Pitfall: scoring by gut feeling instead of writing the numbers down; the value of the rubric is that it survives being questioned by a stakeholder later.
• What changes the ranking: a prior incident (raises likelihood), a compliance requirement (raises impact on security specifically), or a known team-scaling event on the horizon (raises maintainability's score because the Conway's Law cost is about to arrive).
• Under-investing is not the same as ignoring: document the gap, set a revisit trigger (a metric or a milestone), and make sure whoever inherits the debt knows it exists.

The four standard DR tiers form a spectrum from cheapest-and-slowest to most-expensive-and-fastest, and each one trades infrastructure spend for recovery speed (RTO, recovery time objective: how long restoring service takes) and data freshness (RPO, recovery point objective: how much data, measured in time, you could lose): backup-and-restore keeps only backups running, pilot light keeps a minimal always-on core, warm standby keeps a scaled-down full copy running, and active-active multi-site keeps a full copy running and serving live traffic.

Comparing the four tiers

The RTO/RPO ranges above are the typical shape of the trade-off, not a fixed number for any specific system: the exact figures depend on data volume, automation maturity, and how the replication is actually implemented within each tier.

Worked example: a budget-constrained startup

A mid-sized SaaS with a fixed infrastructure budget doesn't have to pick one tier for the whole system; the standard move is to mix tiers by criticality. Say the product has three logical components: authentication/billing (must never meaningfully go down, since it blocks every paying customer from doing anything), the core application (needs to come back reasonably fast but a short outage is tolerable), and internal admin tooling (only the ops team notices if it's down for a few hours).

A budget-conscious allocation: active-active for auth/billing (the one component where the cost premium is justified because its outage blocks revenue entirely, and it's usually small enough in infrastructure footprint that duplicating it fully is affordable), pilot light for the core application (keep the database replicated continuously so RPO stays low, but only spin up the app-server fleet in DR when actually needed, since that's the majority of the compute cost), and backup-and-restore for admin tooling (cheapest tier, acceptable because nobody customer-facing is blocked by it being down for hours). This gets the highest-blast-radius component the fastest recovery while keeping the overall DR bill proportional to what each component actually costs the business if it's down, instead of buying active-active everywhere by default.

Trade-offs and pitfalls

The most expensive mistake in this space isn't picking the "wrong" tier, it's picking a tier and never testing failover into it: a pilot-light setup that's never actually been promoted to full capacity under load is a theoretical RTO, not a real one, and the first real DR event is a bad time to discover the app layer doesn't actually scale up cleanly from zero. A related pitfall is under-provisioning a warm standby's capacity: "scaled down" often means it can absorb DR traffic at reduced performance, and teams sometimes forget to validate that the scaled-down size can actually handle 100% of production load once promoted, not just serve health checks. Finally, active-active's real cost isn't just the duplicate infrastructure line item, it's the ongoing engineering cost of keeping a multi-writer data model correct, which is easy to underestimate when comparing tiers purely on an RTO/RPO/dollar table.

Direct answer: For complex JSON documents with nested objects, arrays, and domain-specific merge rules, the design attaches per-field (or per-path) merge metadata rather than one blanket strategy for the whole document, applies structural rules by field TYPE (scalars use LWW or a domain rule, arrays use set/sequence semantics depending on intent, nested objects recurse the same merge logic), embeds explicit domain rules where the natural type-based default is wrong (ratings take max, tags union), and falls back to surfacing an unresolvable conflict rather than guessing when no rule cleanly applies.

Structured elaboration

Per-path metadata. Rather than one merge function for the whole document, the design tracks, for each JSON path (e.g. $.ratings.overall, $.tags), what KIND of merge applies there: last-write-wins, numeric-max, set-union, or a custom domain function. This is necessary because a single document genuinely mixes fields with very different correct merge semantics, treating them uniformly (e.g. LWW for everything) would be simple but wrong for many fields.

Default rules by structural type. Scalars (numbers, strings, booleans) default to LWW unless a domain rule overrides it. Arrays default to set-union semantics if order doesn't matter for that field (deduplicating by value or by an element ID), or to a sequence-CRDT-style position-preserving merge if order genuinely matters (e.g. an ordered list of steps). Nested objects recurse: the SAME per-path merge logic applies to each nested field independently, so a deeply nested document is handled compositionally rather than needing a special case for depth.

Domain-specific rule examples. "Ratings take max": for a field like $.qualityScore where two concurrent updates might reflect two different reviewers' concurrent submissions, the domain decides the highest score should win rather than an arbitrary last-write, a business rule, not a generic data-structure default. "Tags union": for $.tags, the domain decides concurrent additions from different sources should ALL be kept (set-union) rather than one replacing the other, since tags are additive by nature.

Fallback strategies for impossible merges. Some conflicts have no automatic resolution: two concurrent edits to a deeply structural field (e.g. one edit reshapes $.address from a string to a nested object, while a concurrent edit modifies the OLD string-shaped value), these are genuinely irreconcilable by any generic rule and need to be surfaced explicitly (both candidate document versions, with metadata about the conflicting paths) for human or application-level resolution, rather than the merge engine guessing and potentially producing an internally inconsistent document.

Worked example. A product-review document: $.title (LWW), $.rating (max, per the domain rule that a higher rating from a concurrent update should win, reflecting the reviewer's most positive assessment), $.tags (set-union, so tags added from two different concurrent edit sessions all survive), and $.photos (an OR-Set of photo IDs, so concurrently-uploaded photos from two devices both appear rather than one overwriting the other). Two concurrent edits: edit A sets rating: 4, tags: ["great_service"]; edit B (concurrent, unaware of A) sets rating: 5, tags: ["fast_delivery"]. Merge result: rating: 5 (max rule), tags: ["great_service", "fast_delivery"] (union rule), no conflict surfaced, since every field had a clean, applicable rule.

Trade-offs and pitfalls. The biggest practical risk in this design is an UNDEFINED merge rule for a path silently defaulting to something wrong (e.g. LWW applied to a field that actually needed union semantics) rather than failing loudly during development; a strong version of this design validates, at schema-definition time, that every field in the document has an EXPLICIT merge rule assigned, rather than relying on an implicit fallback that might quietly produce a business-incorrect result in production.