Staff-Level Cloud Architect Interview Preparation Guide (FAANG Standards)

I’d facilitate the conversation around the shared objective first, because people usually disagree on solutions, not the user problem.

My approach:

• Restate the goal and the decision we need to make.
• Ask each function to explain what they need and why.
• Separate must-haves from preferences.
• Use clear criteria: user impact, effort, risk, and release timing.

Then I’d surface the trade-offs openly: if we choose the designer’s version, what slips? If we choose engineering’s approach, what user value do we lose? That makes the decision concrete instead of political.

If the team still can’t align, I’d make the call based on the agreed criteria and explain the rationale. I’d also make sure the decision is documented so nobody feels blindsided later.

What matters most is tone: I’d be firm on the decision but respectful of every viewpoint. People can disagree and still feel heard, which protects the working relationship after the release.

Worked example
Say the release in question is an onboarding redesign: the designer wants a fully polished new flow with custom illustrations and micro-interactions, while engineering proposes a simplified version that reuses existing components to hit the release date. Scoring both against the agreed criteria (user impact, effort, risk, release timing) shows the simplified version delivers most of the user-impact gain at a fraction of the effort and with no timeline risk, while the fully polished version would slip the release by three weeks for a comparatively small additional lift in user impact. So the simplified version ships first, and the custom illustrations and micro-interactions move into a fast-follow scoped for the next release, which is the trade-off made concrete instead of staying a hypothetical "what if."

Direct answer

Use the temporary read replica as the mechanism that turns an in-place resize (which can mean real downtime) into a controlled cutover: provision the replica already at the larger CPU/memory spec, let it fully catch up to the primary, briefly pause writes, promote the replica to primary, and repoint the application. The actual write-unavailability window is bounded by how long it takes to drain in-flight writes and flip the connection target, not by the resize operation itself, which is why this pattern minimizes downtime even though it isn't strictly zero-downtime.

Structured elaboration

Pre-checks

• Confirm the exact target CPU/memory spec against measured load, not a guess, and confirm a maintenance window and a communicated service level objective (SLO, the measurable target for allowed downtime or latency impact) for the operation.
• Take a fresh on-demand snapshot immediately before starting, independent of the replica strategy, as a last-resort fallback.
• Verify current replication lag baseline and that the environment supports creating a same-region replica sized larger than the current primary.
• Confirm the automation (scripts, IaC) for promotion and connection-string cutover has been tested outside of this incident, not written live.

Rolling steps

1. Create a read replica provisioned at the new, larger instance spec. Let it catch up and monitor replication lag until it's negligible and stays that way for a sustained period, not just a single low reading.
2. Briefly quiesce writes on the current primary (put the application into a short read-only or write-paused mode).
3. Promote the replica to primary. Because it was fully caught up at the moment of promotion, this preserves the data that existed at quiesce time.
4. Repoint the application's write target to the newly-promoted primary (a connection-string or routing change, ideally something that doesn't require an application redeploy).
5. Resume writes and run smoke tests against critical read and write paths.
6. Rebuild redundancy: the original (smaller) instance can be resized and re-added as a replica, or replaced, restoring the topology's normal read-replica count.

Fallback options

• If the replica fails to catch up before the maintenance window closes, abort the promotion; investigate whether replication is network- or I/O-bound, and either wait for a longer window or address the bottleneck before retrying.
• If a data mismatch or unexpected inconsistency is detected after promotion, the fallback is the pre-operation snapshot, not the old primary (which may now be behind); restore from snapshot to a fresh instance if this happens.

Monitoring

• Before: replication lag trend over a real observation window, not a single point-in-time check, plus baseline CPU/memory/connection counts to compare against post-cutover.
• During: replication lag right up to the promotion moment, since promoting a replica that's meaningfully behind means losing whatever writes happened after its last applied transaction.
• After: error rates, write and read latency, and a targeted data check (row counts or checksums on a few critical tables, or confirming the most recent known transactions are present) rather than assuming success from the absence of alarms.

Worked example

A safe promotion policy might require replication lag to stay under 1 second for a sustained 5-minute window before promotion is allowed (a stated operational threshold for this runbook, not a universal rule that applies to every workload). The actual write-pause duration during cutover isn't a fixed number worth quoting as a general fact, since it depends on the application's connection pool behavior, not on the database resize itself: it's bounded by how long the app takes to drain in-flight writes and how quickly its clients reconnect to the new endpoint after the connection target flips, which is exactly why this pattern is described as minimizing downtime, not eliminating it. If the application's reconnect and retry logic is slow or missing, the same database-side runbook produces a much longer perceived outage even though the database steps themselves didn't change.

Trade-offs & pitfalls

• This is not truly zero-downtime: promoting a replica that isn't fully caught up loses whatever writes landed after its last applied transaction, so the safety of the whole procedure hinges on verifying lag is genuinely near zero at the moment of promotion, not assuming it.
• If the application cannot tolerate even a brief write-pause, this pattern isn't sufficient on its own; a true zero-downtime requirement needs a different approach, such as a proxy layer that queues writes during cutover.
• Before building a custom replica-promotion runbook, check whether the cloud provider's native "modify instance class" operation already performs an equivalent internal promote-and-swap; if it does, it may be simpler and better-tested than a hand-rolled version of the same idea.
• The replica-promotion mechanics here (catching up, promoting, cutting over) are a practical means to a scaling end; the deeper mechanics of replication modes and failover consensus are a related but distinct topic from the scaling procedure itself.

The build-versus-buy question is really an evaluation-framework question: what does it cost to build and maintain this ourselves, what does it cost to adopt a managed solution, and which risk profile fits the team's actual skills and time horizon.

The evaluation framework

Total cost of ownership over 3+ years, not just sticker price: for building, this means engineer salary time for initial build plus ongoing maintenance, infrastructure costs, and the opportunity cost of that engineering time not going toward the product. For buying, this means license or usage-based fees plus the (often underestimated) integration, migration, and customization work.
Vendor lock-in risk: how hard would it be to leave this vendor later. Standard, open interfaces (SQL, open table formats, exportable metadata) are low risk; a proprietary API that "traps" your metadata or code is high risk.
Time-to-value: building takes months before the first real user benefits; a managed solution can often deliver value in weeks, which matters when the business need is urgent.
Team skills and headcount: building and then operating a component like a data catalog or an orchestrator requires ongoing engineering attention, not just an initial build. A team without a dedicated platform engineer is signing up for perpetual part-time maintenance if it builds.

Worked example: build or buy a data catalog

Say a 500-person company with mixed data maturity is deciding whether to build a lightweight internal catalog (a service plus a UI reading table metadata from the warehouse) or adopt a managed catalog product. Building might cost an estimated 2 engineers for 3 months to reach a usable first version (roughly half an engineer-year), then an ongoing 20 to 30 percent of one engineer's time to maintain and extend it as new data sources are added. Buying costs a recurring subscription fee, but reaches a usable state in weeks rather than months, and the vendor absorbs the maintenance burden of keeping up with new source-system integrations. If the company has no dedicated platform team and catalog needs are fairly standard (ownership, lineage, search), buying wins on time-to-value and total cost once you count engineer time honestly. If the company's catalog needs are unusual (deep integration with a proprietary internal system no vendor supports out of the box), building may be the only realistic option regardless of cost.

How to pilot before committing

Run a bounded pilot, a single team or a handful of high-traffic datasets, on the leading option (build a minimal version, or trial the vendor) for a fixed period, with a small number of concrete success criteria defined up front: does search actually return the right table in under a specified number of clicks, does the team's satisfaction improve, does the pilot surface integration gaps the evaluation missed. A pilot without predefined success criteria tends to be judged only by whether it "felt fine," which doesn't generalize to the full rollout decision.

Trade-offs and pitfalls

The single biggest analytical mistake in these evaluations is comparing the vendor's subscription price directly against a build estimate that only counts initial development time, ignoring the ongoing maintenance a build requires. The second is treating "no lock-in" as an absolute good: a small team may genuinely benefit from accepting some vendor dependency in exchange for never having to think about that component again, if the vendor uses reasonably open interfaces underneath.

Direct answer
Autonomy should track demonstrated judgment in a specific domain, not tenure or title, and it should be granted and withdrawn through visible, structural mechanisms, not just a private mental model of how much you trust someone. As someone grows from junior to senior, both the default level of guidance and the criteria for changing it should become more explicit, not less.

What determines the level, not just the person's level

• Domain-specific, not global: someone can have earned full autonomy in one area (their core service) and need more guidance in an adjacent one (security-sensitive changes) they haven't touched before. Treating autonomy as a single dial per person rather than per domain misjudges both directions.
• Base it on evidence: track record of decisions in that specific domain, not just general seniority or how long they've been on the team.

The conversation isn't enough, structure it

• Guidance and autonomy shouldn't live only in how much you check in; they should be encoded in the system itself. Concretely: mandatory review gates on certain categories of change, feature flags that let risky work ship dark before it's fully trusted, and automated checks (tests, linting, policy gates) that catch the class of mistake a specific person is prone to, rather than relying on a human remembering to look for it.
• This matters especially early: a junior engineer with a mandatory review gate on production-config changes isn't being distrusted personally, the system is compensating for a domain they haven't yet built judgment in, and that's a much less fraught conversation than "I don't trust your judgment yet."

Moving the dial, in both directions

• Define, in advance, what "graduating" out of a guardrail looks like: a number of changes in that domain reviewed without a significant issue, or a specific type of decision made correctly under supervision. Vague criteria ("when I feel comfortable") makes the process feel arbitrary to the person on the other side of it.
• The dial also needs to move backward cleanly. If someone senior makes a judgment error in a domain, temporarily reintroducing a guardrail (an extra review, a smaller blast radius) shouldn't read as a permanent demotion; it should be scoped to the specific domain and have the same kind of explicit, objective path back out.

How this shifts junior to senior

• Junior: guidance is broad and mostly structural (required reviews, smaller scoped tasks, pairing), because there isn't yet enough track record to know where the real gaps are.
• Mid-level: guidance narrows to the specific domains where judgment hasn't been tested yet, while proven domains get real autonomy.
• Senior: guidance becomes mostly about the highest-blast-radius decisions (irreversible changes, cross-team commitments) rather than day-to-day execution, and the structural safeguards that remain exist because the stakes are higher, not because trust is lower.

Worked example
A mid-level engineer had strong judgment in their core service but hadn't touched the deployment pipeline before. Rather than a blanket "you need approval on everything" or "you're trusted, go ahead," the guidance was scoped to that specific gap: full autonomy on their usual work, a mandatory review plus a feature flag for anything touching the deploy pipeline, with an explicit criterion stated up front (three pipeline changes reviewed cleanly, then the mandatory review comes off for that category specifically). That made the guardrail feel like a scoped, temporary compensation for an actual gap rather than a general judgment about their competence, and removing it was a specific, visible moment rather than something that just quietly happened.

Trade-offs and pitfalls

• Treating autonomy as all-or-nothing per person, rather than per domain, either over-restricts someone who's earned trust in most areas or over-extends them into an area they haven't proven yet.
• Relying purely on personal judgment about who to trust, without structural backstops (review gates, flags, automated checks), doesn't scale past a small team and creates inconsistency that reads as favoritism.
• Leaving the criteria for regaining autonomy vague turns a guardrail into something that feels indefinite and punitive, even when it was scoped and reasonable at the start.

Direct answer

Layer 4 load balancers make routing decisions using only transport-layer metadata (source and destination IP, port, protocol) and forward or proxy TCP/UDP connections without looking at the payload. Layer 7 load balancers terminate the application protocol, usually HTTP or HTTPS, and route on request content: host header, URL path, cookies, or other headers. L4 is faster and protocol-agnostic because it never parses the payload; L7 costs more CPU per request but can make far smarter routing, security, and traffic-shaping decisions. Pick L4 when you need raw throughput or must preserve end-to-end encryption; pick L7 when routing needs to understand HTTP semantics.

Structured elaboration

Decision guidance: choose L4 when the balancer must not (or need not) understand the payload, or when throughput at minimal overhead is the priority. Choose L7 when the routing decision itself depends on request content. Many production systems run both: an L4 tier absorbing raw connections at the edge, with an L7 tier immediately behind it for content-aware routing.

Worked example

Consider two systems that need a load balancer. First, a Postgres connection pooler in front of a cluster: clients authenticate to the database itself over TLS, connections are long-lived, and there is no HTTP semantics to route on. An L4 balancer is the right fit here: it forwards TCP connections without touching the encrypted stream, so end-to-end TLS stays intact and per-connection overhead stays minimal.

Second, a public REST API that must send /v1/users and /v1/orders to two different backend services, apply a WAF rule to block known bad user agents, and terminate TLS once at the edge. None of that is possible without reading the request line and headers, so this requires an L7 balancer, even though it costs more CPU per request than the L4 case.

Trade-offs & pitfalls

• L7 termination breaks end-to-end encryption unless the balancer re-encrypts to the backend (TLS bridging); this is a common follow-up in security-conscious interviews.
• L4 cannot do content-based routing or cookie affinity. Bolting host/path logic onto an L4 balancer just pushes the work down a layer where it is harder to operate.
• Hybrid designs (L4 at the outer edge, L7 immediately behind it) are standard practice, not a compromise: the L4 tier absorbs raw connection volume and the L7 tier handles content-aware decisions.
• Common wrong turn: treating L7 as strictly better. It adds a per-request parsing and termination cost and a larger attack surface (header injection, request smuggling) that an L4 balancer never has to reason about.

Direct answer

Meeting a roughly 60-second reroute target for most clients means combining health-check-driven DNS failover (to redirect clients as they re-resolve) with Anycast routing at the network layer (to redirect clients immediately, independent of DNS caching behavior), because DNS alone can't guarantee a hard bound once client-side resolver caching is accounted for.

Architecture

flowchart TD
  Client -->|Anycast IP| Edge[Anycast Edge and CDN]
  Edge --> GSLB[GSLB Health-Aware DNS]
  GSLB -->|healthy| R1[Region 1]
  GSLB -->|healthy| R2[Region 2]
  GSLB -->|healthy| R3[Region 3]
  HC[Active Health Checkers] -->|probe every 5s| R1
  HC -->|probe every 5s| R2
  HC -->|probe every 5s| R3
  HC -->|update after 3 consecutive fails| GSLB
  R1 -.fails.-> HC

GSLB (Global Server Load Balancing, shown in the diagram) is DNS that returns different regional IPs depending on which regions are currently healthy, the mechanism the DNS/load-balancer layer below relies on.

Health checks: active probes (HTTP and TCP, from multiple external vantage points) hit each region every 5 seconds, requiring 3 consecutive failures before a region is marked unhealthy, to avoid flapping on a single transient blip.

DNS/load-balancer configuration: authoritative DNS TTL for the service record is set low, 30 seconds, so clients that honor TTLs re-resolve quickly after a region is marked unhealthy. Anycast IPs are advertised from all three regions simultaneously; when a region fails, its BGP (Border Gateway Protocol: the protocol that advertises which network paths lead to a given IP address) announcement is withdrawn, which reroutes traffic to a healthy region at the network layer almost immediately, without waiting on any client's DNS cache to expire at all.

Worked example: does this hit the 60-second target?

Detection time, the health checker's confirmation that a region is actually down:

For clients relying on DNS re-resolution, the worst case adds the full TTL window on top of detection, since a client could have just refreshed its cache right before the failure:

That leaves 15 seconds of margin against the 60-second target for clients that honor the TTL correctly, covering the large majority of traffic (public recursive resolvers like major DNS providers generally respect low TTLs closely). For the remaining slice of clients behind resolvers that cache more aggressively than the stated TTL (some enterprise resolvers and certain mobile carrier networks), the Anycast BGP withdrawal is what actually gets them under the target: it operates at the network layer and doesn't depend on DNS caching behavior at all, so those clients are rerouted within the same roughly 15-second detection window, not the 45-second DNS-bound one. Combining the two mechanisms is what makes hitting the target for "most clients" (rather than only the well-behaved subset) achievable.

Long-lived connections during cutover

Neither DNS re-resolution nor an Anycast BGP withdrawal preserves an existing TCP connection or WebSocket session that was already established to the failed region; a BGP route change mid-flow actually breaks those connections rather than gracefully migrating them, since the new route doesn't carry the old connection's state. Clients holding long-lived connections need their own reconnect logic (detect the drop, re-resolve or reconnect, resume from the new region) and any in-flight request that was interrupted needs to be safely retryable, which pushes the requirement for idempotent write handling on the server side, since a client that reconnects and retries an interrupted request must not have that retry double-process the original attempt.

Trade-offs & pitfalls

A lower DNS TTL improves worst-case failover time but increases query volume against the authoritative DNS servers and, for high-traffic services, real cost; 30 seconds is a reasonable middle ground rather than pushing to something extremely aggressive like 5 seconds. Anycast gives fast, DNS-independent failover but requires BGP-level control over IP announcements, which is a meaningfully bigger operational lift than DNS alone and isn't available on every cloud platform without specific networking products. The most common mistake in this kind of design is validating the 60-second target only against health-check and DNS timers on paper, without ever measuring how real clients across different resolver populations actually behave in practice, which is the only way to know the theoretical margin actually holds up.

Direct answer

A ransomware-resilient backup design assumes the attacker will eventually hold valid credentials in the production environment, and builds the recovery path so that credential is structurally incapable of reaching the backups: immutable storage (Write Once Read Many (WORM), enforced via Object Lock), a dedicated backup account the production credentials cannot touch, and least-privilege backup operators are the three controls that together mean "the attacker compromised production" does not also mean "the attacker can delete the recovery path."

Structured elaboration

flowchart TB
    subgraph WA["Workload account"]
        App["Application"] --> Prod[("Production data")]
    end
    subgraph BA["Dedicated backup account (separate from workload)"]
        Vault1[("Backup vault, region A, Object Lock: Compliance mode")]
        Vault2[("Backup vault, region B, cross-region copy")]
    end
    Prod -->|"one-way backup role, PutObject only"| Vault1
    Vault1 -->|"scheduled cross-region copy"| Vault2
    Restorer["Restore-test job (least-privilege, read-only)"] -->|"weekly automated restore drill"| Vault1
    Attacker(["Compromised workload credential"]) -.->|"no delete/overwrite permission on vault"| Vault1

Immutable backups (WORM/Object Lock). Object Lock in Compliance mode (not Governance mode, which even an account root user can override) means no principal, including a compromised administrative credential, can delete or overwrite a locked backup object before its retention period expires; this is the single control that most directly defeats a ransomware actor's typical playbook of deleting backups before encrypting production data.

Backup account separation. The backup destination lives in a dedicated AWS account (or equivalent project/subscription on GCP/Azure) that the production workload's own credentials have no delete or administrative access to at all, only a narrow, one-way write path. This means a full compromise of the production account's identity and access management (IAM), including a compromised administrator credential in that account, still cannot reach into the backup account to remove the recovery path, since that permission was never granted in the first place, not merely restricted.

Cross-region replication strategy. Backups replicate to a second region on a scheduled basis, protecting against a region-level event independent of ransomware specifically (an infrastructure outage, a regional service disruption), and adding a second layer of recovery even in the unlikely case the primary backup vault's own region is somehow compromised.

Backup encryption and Key Management Service (KMS) key separation. Backup data is encrypted with a KMS key that lives in the backup account, not the production account; a compromised production credential cannot decrypt, and more importantly cannot request deletion of, a key it was never granted access to. Key separation matters as much as account separation, since a shared key would leave decrypt access reachable from production even if the storage itself were otherwise isolated.

Least-privilege for backup operators. The identity that writes new backups holds exactly PutObject (and equivalent) permission on the vault, nothing else, no delete, no ability to modify Object Lock settings, and no read access to unrelated data; the identity that runs restore tests holds read-only access scoped to the vault, never write or delete. Neither identity is broad enough to undo the immutability guarantee even if it were itself compromised.

Automated testing of restores. A scheduled job performs a genuine restore, not just a checksum verification, on a regular cadence (weekly, in the diagram above), because a backup that has never actually been restored is an unverified assumption, not a working recovery capability; ransomware-readiness reviews routinely find backups that technically exist but fail to restore when actually needed.

Cost controls. Immutable, cross-region, versioned backups accumulate storage cost indefinitely unless a lifecycle policy transitions older, still-locked backups to a cheaper storage tier after their compliance-critical recency window passes, and eventually expires versions once their retention period is satisfied; cost control has to be designed alongside immutability, not treated as a reason to shorten retention below what the recovery objective actually requires.

Detection signals for ransomware activity. A sudden spike in file-modification or encryption-pattern activity across a filesystem or object store; an unusual volume of PutObject calls overwriting existing keys in rapid succession; a spike in failed decryption or file-open errors reported by monitoring agents; and, specifically relevant to the backup design itself, any attempted delete or Object Lock modification call against the backup vault, which should never happen legitimately and is a near-certain indicator of an attack in progress given the least-privilege design above.

Immediate playbook actions. Isolate the affected workload (network-level quarantine, not deletion, to preserve forensic evidence) the moment ransomware activity is detected; confirm the backup vault's integrity and immutability status independently, since this design assumes it cannot have been touched, but confirming that assumption explicitly is still the first recovery-readiness check; identify the last known-clean restore point using the tested restore capability; and begin restoring to a clean, isolated environment rather than back into the still-compromised production account.

Worked example

A ransomware actor gains administrator-level credentials in a company's production AWS account through a phishing attack and begins encrypting data across the account's storage. Detection: the security team's monitoring flags an unusual spike in PutObject calls overwriting existing object keys across several buckets within a short window, well outside the account's normal write pattern. Immediate action: the affected instances and their network access are isolated. The team confirms, as designed, that the attacker's credentials, scoped entirely within the production account, have no path to the separate backup account at all; an attempted DeleteObject call against the backup vault (which the attacker's automated ransomware tooling did in fact attempt, per the design's detection signal) is denied outright by IAM before it ever reaches the Object Lock check, since the compromised credential was never granted delete permission on that account in the first place. Recovery proceeds from the most recent tested restore point, into a newly-provisioned, isolated environment, not back into the still-potentially-compromised original account.

Trade-offs and pitfalls

• Governance mode is a common, dangerous shortcut. It is easier to configure than Compliance mode because it permits an override by a sufficiently privileged principal, but that is exactly the property ransomware exploits if the attacker's compromised credential happens to hold that override permission; Compliance mode's inflexibility is the actual point of the control, not a limitation to work around.
• Backup account separation only holds if the separation is genuinely one-way. A backup account that grants the production account any administrative or delete-capable role back into itself (even one intended only for emergency operator use) reopens exactly the path this design exists to close; any emergency access needs to be a separate, tightly audited, out-of-band process, not a standing IAM relationship.
• Untested restores are the single most common gap discovered during an actual ransomware incident, not a hypothetical risk. A backup program with excellent immutability and account separation but no regular, automated restore testing can still fail at the moment of truth if the backup format has silently drifted from what the restore tooling expects; the weekly restore drill in the design above is not a nice-to-have, it is the control that validates every other control actually works end to end.
• Cost controls that shorten retention below the actual recovery objective undermine the whole design for the sake of a smaller storage bill. A retention window shortened to save cost, without re-evaluating whether it still covers a realistic "time to detect a slow, stealthy ransomware campaign," can leave the organization with only encrypted, already-compromised backups by the time the attack is finally noticed.

Partitioning by date improves performance by pruning irrelevant partitions, improving I/O, and enabling parallel processing and easier maintenance.
For 10 years of daily transaction lines use RANGE partitioning by month (e.g., partition per month) or per-day if query patterns require very fine pruning. Monthly partitions balance number of partitions (~120) vs partition size; daily partitions (~3650) can be heavier to manage.
Scheme: RANGE on order_date using monthly boundaries. Benefits: most queries filter by month/day so planner prunes partitions; maintenance (drop/archive old partitions) is straightforward; backfill and bulk loads target single partitions. Use partitioned indexes or global indexes depending on DB. Choose daily only if queries frequently filter by exact day and single-day partitions are required for performance.

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:

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: 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.

Direct answer

Expect Redis to win a leaderboard-shaped write-heavy benchmark, because its sorted-set data structure is purpose-built for exactly this access pattern, with Cassandra as the fallback once the working set genuinely outgrows what fits comfortably in memory, and PostgreSQL as the control that will most likely lose on raw write throughput but establishes the transactional-safety baseline the other two are measured against. That expectation is a hypothesis, not the answer: the actual answer to "evaluate three candidates" is the benchmark design below, built so the result is decided by measurement, not by which system sounds best on paper.

Structured elaboration

Benchmark scenarios to define, each with an explicit target, not a vague description.

Failure modes to test, one per candidate plus one cross-cutting. Node or primary failure mid-write-burst: for Redis, verify whether a failover (the automatic process of promoting a standby replica to primary and redirecting traffic when the current primary goes down) during an unacknowledged asynchronous replication window can lose the most recent writes, and whether that risk is acceptable or needs to be closed with a stronger write-acknowledgment setting (accepting the latency cost of waiting for a replica to confirm). For Cassandra, verify behavior under a network partition: does it continue accepting writes per the configured consistency level, and do replicas correctly reconcile once the partition heals. For PostgreSQL, verify failover behavior with a managed or self-managed replication topology and measure how long writes are actually unavailable during the failover window. Cross-cutting: run a genuine network partition or node-kill during the sustained peak load from the writes/reads targets above, not against an idle system, since failure behavior under load is the behavior that matters.

Metrics and service-level objectives (SLOs) to observe. Write latency, p50 and p99. Read latency, p50 and p99. Read-after-write staleness distribution (not just an average, the tail is what a user actually notices). Replication lag under load. Error rate during the fault-injection window. Time to return to SLO-compliant behavior after a failure resolves. And one candidate-specific early-warning metric each: for Redis, memory headroom against maxmemory and the active eviction policy (if the working set exceeds available memory, Redis evicts keys per policy, commonly least-recently-used, which can silently and incorrectly drop leaderboard entries if the eviction policy is not deliberately scoped away from leaderboard keys); for Cassandra, compaction backlog (a growing backlog under sustained high write rate is the leading indicator that read latency is about to degrade, well before it visibly does); for PostgreSQL, table and index bloat ratio from autovacuum lag (a write-heavy pattern that repeatedly updates the same rows, exactly what leaderboard score updates do, is the classic case that causes PostgreSQL's multi-version concurrency control, MVCC, to accumulate dead row versions faster than autovacuum reclaims them, degrading both read and write latency over time if unaddressed).

Why these three failure modes are not interchangeable, and why they matter more than the raw throughput numbers. A benchmark that only measures steady-state throughput will make all three candidates look reasonable; the failure modes above are each a specific, well-known weak point of a write-heavy pattern on that particular engine, and a benchmark that skips them will not catch the actual production incident each engine is prone to.

Worked example

Derive the writes/sec and reads/sec targets from a stated scenario, and check Redis's working-set memory budget against a stated player count, since memory headroom is the single most consequential capacity question for a Redis-based design.

# benchmark target derivation for a write-heavy leaderboard.
players = 5_000_000
updates_per_player_per_day = 40      # match/score events per active player per day
writes_per_day = players * updates_per_player_per_day
writes_per_sec_avg = writes_per_day / 86400
peak_multiplier = 6                  # evening/event-driven peak concentration
writes_per_sec_peak = writes_per_sec_avg * peak_multiplier
print(f"avg writes/sec = {writes_per_sec_avg:,.0f}, peak writes/sec (x{peak_multiplier}) = {writes_per_sec_peak:,.0f}")

# Redis working-set sizing for a large leaderboard.
lb_players = 20_000_000
bytes_per_entry = 200                # member id + score + sorted-set node overhead, illustrative
working_set_gb = lb_players * bytes_per_entry / 1e9
replication_factor = 2               # primary + 1 replica for HA
headroom = 1.3
total_ram_gb = working_set_gb * replication_factor * headroom
print(f"working set = {working_set_gb:.1f} GB for {lb_players:,} players")
print(f"RAM budget with {replication_factor}x replication and {headroom}x headroom = {total_ram_gb:.1f} GB")

# avg writes/sec = 2,315, peak writes/sec (x6) = 13,889
# working set = 4.0 GB for 20,000,000 players
# RAM budget with 2x replication and 1.3x headroom = 10.4 GB

Two results worth acting on. First, peak write load (about 13,900 writes per second under these stated assumptions) is well within what all three candidates can sustain in isolation; the benchmark's value is in the failure-mode and tail-latency behavior at that load, not in whether any of the three can technically keep up. Second, a 20-million-player leaderboard's working set is only about 4 gigabytes, comfortably fitting in a single modestly sized Redis instance with room to spare for replication and headroom, well under commonly available managed-instance memory tiers. The real trigger for moving off Redis toward Cassandra is not this leaderboard's size, it is a leaderboard an order of magnitude or two larger, or one that needs to retain full historical score events (not just current standings) indefinitely, which no longer fits an in-memory design economically.

Trade-offs & pitfalls

• Benchmarking only steady-state throughput. All three candidates will look acceptable; the failure modes above are where the real differentiation, and the real production risk, actually lives.
• Assuming Redis's async replication failover is safe by default. It is not, without an explicit stronger write-acknowledgment configuration, which trades some write latency for the durability a leaderboard's ranking correctness actually needs.
• Missing a Cassandra compaction backlog until read latency has already visibly degraded. Compaction backlog is a leading indicator specifically because it degrades before the symptom (slow reads) becomes obvious; alert on the backlog metric itself, not just on read latency.
• Treating PostgreSQL's bloat risk as a generic "Postgres is slower" conclusion, rather than the specific, addressable cause it is: hot-row updates outrunning autovacuum. Tuning autovacuum aggressiveness for the specific hot table, or restructuring the update pattern, is a real fix, not a reason to dismiss PostgreSQL outright for smaller-scale versions of this workload.
• Setting the read-after-write latency SLO too strictly for the actual product requirement. A live global leaderboard tolerating roughly a second of staleness is normal and expected; over-specifying "instant" consistency here adds real engineering cost for a UX improvement users are unlikely to notice.