Airbnb Senior Software Engineer Interview Preparation Guide

Direct Answer

I gave them real leadership surface area before the title changed, not a reading list, running part of a meeting, owning a small project end to end, giving feedback to a peer, so what I was actually assessing was how they behaved with authority, under pressure, and with imperfect information, not just whether they said the right things about leadership.

Framework

What "prepare them" actually meant in practice: shadowing with a handoff rather than just observing, where they ran part of a 1:1 or a triage themselves with me present, then we debriefed; a bounded leadership trial, owning something small end to end, planning, coordinating with others, being the point of contact, with a real but limited blast radius if it went wrong; deliberate exposure to the parts of the job that aren't visible from the IC seat, prioritization tradeoffs, giving feedback that isn't well received, defending a decision to someone who disagrees; and a structured way to reflect on each of these, naming what they learned so it generalized beyond the specific situation.

To evaluate whether it was working, I looked for changes in how they handled ambiguity and pushback specifically, since that's the part of leadership hardest to fake or coach quickly: did they make a call and hold it under mild disagreement, or fold immediately; did they proactively flag a risk before being asked, or wait to be told.

Worked Example

Someone technically strong on my team wanted to move toward tech lead. Rather than a development-plan document, I gave them ownership of a real but contained piece of work: they ran planning for it, coordinated with the two other people involved, and I stayed available but stepped back from decisions I'd normally have made. The useful moment wasn't when it went smoothly, it was when a dependency slipped and they had to renegotiate scope with someone more senior than them. Watching how they handled that, calmly, with a clear ask rather than an apology, told me more than months of 1:1s about how leadership would actually work when the stakes went up.

Trade-offs and Pitfalls

• Giving someone the title before the trial, rather than the trial before the title, removes the one thing that actually tells you whether they're ready.
• Staying too involved during the trial defeats the purpose. Making every call for them evaluates your own judgment, not theirs.
• Not protecting their existing technical credibility during the transition, letting their technical skills visibly atrophy while they're still proving themselves as a leader, can undercut trust from the team they're about to lead.
• A senior answer describes a real trial with a moment of pressure in it; a junior answer describes a training plan with no evidence anyone was actually tested.

A strong executive status update should answer four questions quickly: are we on track, what changed, what is at risk, and what do you need from me?

I’d include:

• Overall status: green, yellow, or red
• Progress against key milestones
• Delivery confidence and why it changed
• Top risks or blockers
• Decisions, escalations, or support needed
• Business impact, such as launch timing, customer value, or revenue risk

For a non-technical audience, I’d translate technical progress into business language. Instead of saying “the API refactor is 80% done,” I’d say “the backend work needed to support launch is mostly complete, which reduces release risk.”

I’d keep details at the right altitude: enough context to make a decision, not a deep implementation report. If leadership wants more detail, I’d offer an appendix or separate follow-up. The goal is clarity, not completeness.

Direct answer

Without formal authority (the ability to simply mandate the outcome), influence over four independent teams comes from making the shared platform API (the common interface other services call instead of each building their own version) the easiest path, not the required one, and from investing more in the coordination mechanics than in the pitch itself. My plan front-loads stakeholder mapping and a working pilot before asking anyone to commit.

Stakeholder mapping

For each of the four teams I identify: the tech lead (technical buy-in), the engineering manager (roadmap and headcount trade-off), and one senior engineer who will actually do the migration work and can spot integration problems I can't see from outside. I map each team's current pain point (duplicated logic, inconsistent error handling, a recent incident caused by drift between their bespoke implementations) because the pitch is different for each team depending on what already hurts them.

Communication cadence

• A one-time kickoff to align on the problem statement and get agreement that a shared API is worth exploring, not yet a commitment to adopt.
• A sync every two weeks, 30 minutes, across all four teams' representatives to track pilot progress, blockers, and API design feedback, so no team is surprised by a decision made in a side channel.
• Async written updates (a short changelog-style doc) after every sync, because the teams are spread across time zones and a live meeting cadence alone would exclude whoever is asleep during it.

Cross-timezone coordination

Because the four teams span multiple time zones, there is no meeting time that is fair to everyone, so the slot rotates and I state the shape of the rotation when I set it up. With four teams and one sync every two weeks, a full rotation is four syncs, which is eight weeks, and each team absorbs the awkward slot once in that window. I say the eight weeks out loud and keep the slot table next to the meeting notes, because a rotation whose period nobody can see reads as favoritism rather than as a schedule, and because eight weeks is slow enough that somebody will otherwise conclude their turn is never coming. If the pilot is producing decisions faster than that, the honest fix is to move the sync to weekly, which shortens a full rotation to four weeks, rather than to leave the same team on the 6am call while I tell them a rotation exists. I record every session with a written summary posted within an hour so a team member who couldn't attend live can react asynchronously before the next decision point. Design reviews and API contract proposals go through a 48-hour async comment window before I treat silence as approval, rather than requiring live attendance to have a voice.

Pilot strategy

I recruit the team with the most acute current pain as the first adopter, since they have the strongest incentive to push through migration friction and become a credible reference for the other three. The pilot ships with the old and new paths running in parallel for a full release cycle before the old path is deprecated for that team, so the pilot team never faces a forced cutover risk.

Success criteria for voluntary adoption

• The pilot team's integration time for a new feature drops relative to their historical baseline using the old bespoke approach.
• Zero P1 (highest-severity, all-hands) incidents attributable to the shared API during the pilot window.
• At least one of the remaining three teams asks to join based on the pilot's results, without being asked, which is the real signal that word-of-mouth influence is working instead of a mandate.

Trade-offs and pitfalls

Running two code paths in parallel during the pilot costs the platform team extra maintenance, and voluntary adoption is slower than a mandate. I accept that trade because a team that is forced onto a shared API without believing in it tends to work around it at the first opportunity, recreating the fragmentation I was trying to remove. The eight-week rotation is a real cost of the voluntary approach too: the same fairness mechanics that make a team feel heard also make the schedule slow, and if a decision cannot wait for the next sync it goes into the 48-hour async window rather than into whichever call the loudest time zone can attend.

Direct answer. Technical debt is choosing a faster, less durable way to build something now, with the understanding that it will cost more time later to fix properly -- like taking on a loan: useful when deliberate and tracked, costly when it accumulates unnoticed and unpaid.

Measurable indicators, not just a feeling

1. Rework rate: the percentage of engineering time spent fixing/adjusting existing features versus building new ones -- a rising trend is a concrete signal debt is compounding, even if nobody can point to a specific 'debt item.'
2. Time-to-ship a comparable feature, over time: if similar-sized features are taking measurably longer to build than they did a year ago, that's debt manifesting as friction, trackable via delivery data rather than opinion.
3. Incident rate tied to a specific area: if one part of the system accounts for a disproportionate share of production incidents relative to its size, that's a concrete, defensible signal of where debt is actively costing the business, not just where code 'looks messy.'

Why concrete indicators matter more than a vague appeal

A non-technical stakeholder can't evaluate 'this code is ugly' as a basis for prioritizing engineering time, but they CAN evaluate 'feature delivery in this area has slowed 40% over two quarters, and it accounts for 25% of our incidents despite being 10% of the codebase' -- the same underlying reality, translated into terms that connect to business outcomes they already track.

Framing it as a trade-off, not a moral failing

Debt isn't inherently bad -- shipping fast with a known shortcut, TRACKED and communicated, is often the right call under real deadline pressure. The problem is UNTRACKED debt (nobody decided to take it on, it just accumulated) or debt that's never revisited despite compounding cost. Framing it this way (a deliberate, trackable trade-off) tends to land better with stakeholders than framing it as 'the code is bad,' which reads as a complaint rather than a decision point.

Trade-offs and pitfalls

• Avoid using 'technical debt' as a catch-all excuse for any code a stakeholder doesn't like the shape of -- reserve the term (and the indicators) for genuine, measurable friction, or the concept loses credibility with stakeholders the first time it's invoked for something that turns out not to matter.
• Indicators can be gamed or misread (a spike in rework could reflect a genuinely hard new requirement, not accumulated debt) -- pair quantitative signals with a concrete qualitative example stakeholders can understand, so the number isn't the whole argument.

Direct answer
Culture fit asks whether you already share a team's existing norms and behaviors; culture add asks what you would bring that the team does not already have. I would describe myself mostly as a culture add: I share the fundamentals a team needs to trust me (reliability, candor, respect for other people's time), but the useful thing I offer beyond that is a genuinely different working background rather than a mirror of the team that is already there.

Structured elaboration

1. Define both terms precisely before answering for yourself. Culture fit is about alignment on shared behaviors and values: does this person operate the way we already operate. Culture add is about complementary difference: does this person's background, working style, or perspective fill a gap the team doesn't currently have.
2. Explain why the distinction matters, not just define it. A team optimized purely for fit tends toward groupthink: everyone reasons the same way, so blind spots go unchallenged and the same kinds of mistakes recur. A team that only adds without any shared fit becomes uncoordinated: people can't predict each other's reasoning enough to move fast together. The healthy target is fit on a small number of load-bearing behaviors (honesty, follow-through, respect) plus deliberate add on everything else.
3. Give a genuine, specific example of your own add, not a generic trait. Vague claims ("I bring diverse perspectives") are the single most common failure mode here; a strong answer names the concrete gap and the concrete evidence.
4. Anticipate the natural follow-up: how do you know your difference is actually useful, versus just different for its own sake. The answer is to point at a specific decision, disagreement, or piece of feedback that changed because of the difference you brought, not just a credential or background fact.

Worked example
Suppose your last two teams were both product engineering teams building consumer-facing features, and the team you're interviewing for is mostly staffed by engineers with that same background. Your own prior role was on a data-platform team, closer to the systems that feed those consumer features than to the features themselves. A concrete add-story: in a past project, a product team wanted to ship a new recommendation feature quickly; because of your platform background, you asked a question the rest of the team hadn't raised (whether the upstream data pipeline's freshness guarantees actually matched what the feature's UI implied to users), which surfaced a real gap between a 24-hour batch refresh and a UI copy that said "updated just for you." The team fixed the copy and adjusted the refresh cadence before launch rather than after a user complaint. That is a genuine add: a different background produced a question the existing team composition was less likely to ask on its own, and it changed a real outcome.

Trade-offs & pitfalls
The common failure is answering only the definitional half (correctly explaining fit versus add) and then, when asked for a personal example, retreating to generic self-description ("I'm a good communicator", "I care about quality") that any candidate could say and that does not actually demonstrate difference. A second pitfall is overcorrecting into implying you don't fit at all; the strongest answers are explicit that you also share the small set of behaviors every functioning team needs, and that add is about everything on top of that baseline, not a replacement for it.

Direct answer

A proposal was about to go out to a client built on an assumption from a regulatory area outside my usual scope, and nobody had actually verified it held. Since no one else had the bandwidth and it wasn't formally assigned to me, I picked it up myself, worked it in around existing commitments over about a week and a half, and it changed the outcome directly: the assumption turned out to be wrong.

Structured elaboration

Why the gap mattered to the business, not just to me personally: committing resources to a flawed assumption would have cost far more to unwind later than the time it took to check it up front, so this wasn't learning for its own sake, it was risk that had a real dollar and reputation cost attached.

How I fit it around existing delivery: a few focused hours most days, worked around my actual deliverables rather than replacing them, which is closer to the honest reality than pretending I found a clear open runway.

What I chose to learn from and why: the primary source material for the regulation itself, plus one conversation with someone closer to that domain to sanity-check my reading, rather than a general course, because the timeline didn't allow for breadth and precision mattered more here than depth of background.

The first real application and how I checked it before it counted: I used what I'd learned to redline the specific assumption in the proposal, then had the person closer to that domain review that specific change before it went out, since being self-taught on something this consequential doesn't make me the final authority on it.

Worked example

The flawed assumption got caught and corrected before the proposal went out, which avoided a costly rework and a credibility problem with the client later. What I'd do differently next time: flag the gap the moment I noticed it, rather than only surfacing it once the proposal was nearly final, which gave less room to fix it calmly. It's also worth naming the distinction directly: this is a stronger example precisely because nobody assigned it to me, I noticed the gap and closed it on my own, which is a different and harder signal than closing a gap someone else already identified for me.

Trade-offs and pitfalls

A common wrong turn in this kind of answer is treating "learning outside my expertise" as a story about personal growth in the abstract, disconnected from why the business actually needed it. The other is overstating the depth reached: the honest version isn't "I became an expert in it," it's "I got enough to catch the specific risk and knew to verify the fix with someone deeper in the area before it shipped."

Direct answer

I require a short, focused pre-read before the meeting (the problem, the options, the data behind them, not a pitch for one answer), invite the people who'll actually operate or approve the outcome rather than everyone remotely interested, and when two attendees disagree I redirect the conversation from stated positions to the underlying constraints each of them is protecting, then settle it against evidence rather than whoever argues longer.

Pre-reads I require

A two-page document, sent enough in advance that people arrive having actually read it: the problem and current metrics, the options actually being considered (not one option dressed up as several), rough cost and risk for each, and any prototype or benchmark data available. I explicitly ask people to bring disagreement in writing beforehand if they have it, so the meeting starts from known positions instead of surfacing them live for the first time, which burns the room's limited time on restating context instead of resolving disagreement.

Who I invite

The engineers who will build and the ones who will operate the result, since design-time convenience and runtime cost are often in tension and both need a voice. A reliability-focused reviewer if the change affects availability or incident risk. A security reviewer if the change touches data access or the trust boundary, since security is easy to leave out of an architecture conversation and expensive to add back in later. A product stakeholder if the change affects what's shippable or when. If a technical program manager is involved, they typically own getting the pre-read circulated and the room booked with the right people, not the technical recommendation itself, and keeping that distinction clear avoids the meeting drifting into project-status territory. I keep the list to the people who need to decide or will be materially affected, not everyone who might find it interesting; a design review that tries to include everyone stops being a decision-making meeting.

Handling genuine disagreement in the room

When two people show up with real, substantive disagreement rather than a misunderstanding, I don't try to referee it as a personality conflict. I ask each to state the specific constraint they're protecting in concrete terms (a latency floor, an operational complexity ceiling, a data-consistency guarantee) rather than their preferred solution, because two people arguing for different solutions are often actually protecting the same underlying concern and don't realize it. Then I score the options against those stated constraints using whatever data is on the table, prototype numbers if we have them, rather than letting the debate resolve on seniority or persistence. If the data genuinely doesn't settle it, I say so explicitly and either scope a short follow-up spike to get the missing data or make the call myself as the meeting owner and document why, rather than letting the meeting end without a decision.

Worked example

A notification service was missing its latency target under peak load, and I ran the design review to replace a single-worker batch processor with something that would scale. The pre-read covered current metrics, three real options (a streaming platform with partitioned consumers, a sharded worker pool, a managed publish-subscribe service), and prototype latency numbers I'd gathered beforehand. I invited backend engineers, an SRE, a product manager, and a security reviewer given the service touched user contact data. The SRE favored the managed option for lower operational burden; backend engineers favored the streaming platform for control over partitioning and failure isolation. I asked each to state the constraint they were protecting: the SRE's was on-call load, backend's was avoiding a hard ceiling on horizontal scaling. The prototype data showed the streaming option met the throughput target with acceptable, quantified operational overhead, which resolved it on evidence rather than preference. We agreed the meeting owner (me) would write up the decision and the operational commitments needed to satisfy the SRE's concern, closing the loop instead of leaving it as an unresolved parallel objection.

This same shape scales down and up: a narrower change, like an internal billing application programming interface, might only need a focused hour with the engineers, quality assurance, and one product stakeholder; a platform-wide move needs the fuller group and probably more than one session.

Trade-offs and pitfalls

• Skipping the pre-read and using the meeting itself to build shared context. That turns a decision meeting into a status meeting and wastes the room's actual purpose.
• Inviting too many people "to be safe." A design review with fifteen attendees rarely reaches a decision; it reaches a list of concerns.
• Treating disagreement as something to smooth over instead of resolve. Letting two people leave with different unstated assumptions about what was decided just moves the conflict to implementation time, where it's more expensive.
• Ending the meeting without an owner for follow-up. A design review that produces a direction but no named owner for the write-up and next steps tends to lose momentum within days.

Direct answer

Keep exactly one path for reads that must be linearizable, meaning the read is guaranteed to see every write that completed before the read began, and give everything else a cheaper path that trades a bounded amount of staleness for a shorter round trip. The three techniques below differ only in how they let something other than a full leader round trip answer safely, without breaking the guarantee for the reads that actually ask for it.

Technique 1: bounded-staleness follower reads

Each replica tracks the highest write position (a log index or sequence number) it has applied. A client that can tolerate some staleness issues a "read as of no more than X positions old" request to its nearest replica; if that replica's applied position is within X of the leader's latest, it answers locally. A strict "give me the current value" request is never eligible for this path and always goes to the leader (or through one of the other two techniques below).

Technique 2: leader lease reads

The leader holds a time-bound lease, renewed through its normal heartbeat or replication round trip with followers, that certifies no other node could have become leader before the lease expires. While the lease is valid, the leader can answer a read from its own local state without running a fresh round of consensus for that specific read, because the lease itself is the proof no newer leader could have committed a write elsewhere in the meantime. This only removes the coordination round trip, not the trip to the leader itself, so it mainly helps latency when the leader happens to be close to the requester; it does not by itself let a remote follower answer.

Technique 3: read-index protocol (two-tier API)

Before answering a strong read, the leader (or a follower proxying to it) records the currently committed log index, the "read index", and confirms with a lightweight quorum check-in, not a full new log entry, that it is still the leader. It can then let any replica serve the read once that replica's own applied index has reached the read index, including a nearby follower, without paying for a full consensus round trip per read. Exposing this as two API surfaces, a ReadStrong() that always uses the read-index path and a ReadFast() that skips straight to the nearest replica's current state, lets the client declare which guarantee it actually needs.

Worked example: comparing index positions

A product's price is replicated with a monotonically increasing log index. The leader's last committed index is 582. A follower in a remote region has an applied index of 579, three entries behind due to ordinary asynchronous replication lag.

• Strict read request: the system requires the answering replica to show an applied index of at least 582 before answering. The remote follower, at 579, does not qualify, so this read is served either by the leader directly, or the follower must first catch up to 582 (via read-index or a direct proxy).
• Bounded-staleness read request, tolerance = 10 positions: the remote follower's applied index (579) is only 3 behind the leader's 582, well within the stated tolerance of 10, so it answers locally with no round trip to the leader at all.

This is the actual mechanism behind "reduce latency for reads that don't need the freshest value": comparing an explicit applied-index number against an explicit, stated tolerance, not a vague notion of "probably fresh enough."

Trade-offs & pitfalls

The most common pitfall across all three is exposing a fast path and a strong path as separate API calls and then trusting the client to pick correctly every time; a safer design escalates automatically, for example retrying as a strong read when a fast read's own returned version looks suspiciously far behind what was expected, rather than relying solely on the caller's judgment.

Direct answer

All three separate business logic from input and output code; they differ in which way the dependencies point. In a classic layered architecture, presentation depends on business logic, which depends on data access, so the business layer knows about the database code beneath it. In hexagonal (ports and adapters) architecture, the business core defines interfaces called ports for what it needs and offers, and adapters (HTTP controllers, database code, message consumers) plug into them, so the database code depends on the core instead. Clean architecture is the same inward-pointing rule with more named rings (entities, use cases, interface adapters, frameworks). Recommend layered for CRUD-heavy services with one UI and one database; move to hexagonal when the service has several ways in or out or a domain worth protecting; reserve full clean architecture for large, complex, long-lived domains.

The key difference: direction of dependency

flowchart TB
    subgraph Layered
        P1[Presentation] --> B1[Business]
        B1 --> D1[Data access]
    end
    subgraph Hexagonal
        H[HTTP adapter] --> Core[Domain core with ports]
        K[Queue adapter] --> Core
        PG[Postgres adapter] --> Core
    end

In the hexagonal half, the Postgres adapter points to the core because it implements a port the core declared (for example PriceRuleStore). That is the dependency inversion principle: high-level policy does not depend on low-level detail; both depend on an abstraction owned by the policy.

• Driving (primary) adapters call into the core: REST controllers, CLI, message consumers.
• Driven (secondary) adapters are called by the core through ports: databases, payment APIs, email.
• Clean architecture's rings: entities (the core business objects and rules that would still make sense even outside this app, such as an Order and how its total is computed), use cases (the app-specific steps that orchestrate entities to do one thing, such as "place an order"), interface adapters (translators at the edge: controllers turn an incoming request into a use-case call, presenters format a use case's result for display, gateways implement a port, such as talking to a database), frameworks and drivers (the outermost layer: the actual web framework and database driver code). Its dependency rule: source-code dependencies only point inward.

Comparison on the three asked axes

Both team-boundary points are within one service's codebase. Which services a team owns is a separate decision; these patterns shape how people collaborate inside one codebase.

Worked example: a pricing service

Requirements: price rules are stored in PostgreSQL; competitor prices come from a partner HTTP API; prices are requested over REST, by a nightly batch file and, next quarter, from a Kafka topic (a named event stream in Kafka, a distributed message queue other services publish to and read from).

• Layered. PricingService imports PostgresRuleDao and PartnerHttpClient directly. Unit-testing a price rule means starting a database or mocking two concrete classes. Adding the Kafka input means another entry point calling into a service already shaped around the REST request object.
• Hexagonal. The core declares 2 driven ports (PriceRuleStore, CompetitorPriceFeed) and 1 driving port (QuotePrice). REST, batch and Kafka are 3 driving adapters; Postgres and the partner client are 2 driven adapters. Adding Kafka next quarter touches 0 core files. Price rules get fast tests with in-memory fakes of both driven ports.
• Cost, counted for one new field. In the layered version, adding currency touches roughly the request DTO (data transfer object), controller, service, entity, DAO (data access object, the class that talks to the database for one table) and migration (the schema-change script that applies the new column): 6 places. In a strict clean-architecture version it also touches the use-case request and response models, the presenter and one or more mappers, roughly 10. The exact count depends on the codebase, but the direction is the point: more boundaries, more mapping per change.

Recommendation for this service: hexagonal. It has three driving inputs and two external dependencies, which is exactly where ports pay back. Full clean architecture would add presenter and use-case-model ceremony without a second UI to justify it. A thirty-endpoint internal admin CRUD service would get plain layered, perhaps with a repository interface owned by the business layer as a cheap middle step.

What would flip it: if the service stays at one input and one database for its life, hexagonal's extra interfaces are ceremony. If the domain grows complex enough that several teams work in the same codebase, clean architecture's stricter rings start to earn their cost.

Pitfalls

• Hexagonal in name only. Port interfaces that return ORM entities (the database-mapped objects an object-relational mapper generates, such as a Hibernate or Active Record model) or HTTP types leak the adapter into the core; the core then depends on the framework anyway.
• One port per table. Ports should describe what the domain needs ("find active rules for SKU", a stock keeping unit, the code that identifies one specific product), not mirror the schema.
• Pattern as a golden hammer. Applying clean architecture to a CRUD service produces many files that only copy fields between near-identical objects.
• Layered done lazily. Letting presentation code skip the business layer and query the database directly ("layer skipping") removes the one benefit layering had.

Direct Answer

Route queries by data age: hot is optimized for write and point-lookup latency at full resolution, warm keeps full resolution but trades write-path speed for better compression, and cold and archive downsample aggressively and lean on cheap object storage, accepting slower, block-oriented reads. The tiering only pays off if you also downsample, keeping full resolution for 7 years costs an order of magnitude more than the numbers below show.

Structured Elaboration

Rehydration is bounded by making every tier block-addressable by time range and label hash: a query for a specific series over a specific window only pulls the blocks that could contain it, using the manifest's Bloom filters (compact per-block structures that can say "this block definitely doesn't contain that series" without opening it) to skip the rest, rather than scanning a tier wholesale.

Tier flow

flowchart LR
  Q["Query Router"] --> HOT[("Hot: 1 day")]
  Q --> WARM[("Warm: 30 days")]
  Q --> COLD[("Cold: 1 year, downsampled")]
  Q --> ARC[("Archive: 7 years, downsampled")]
  HOT -->|"compaction"| WARM
  WARM -->|"downsample to 5min"| COLD
  COLD -->|"downsample to 1hr"| ARC
  ARC -.->|"on-demand rehydrate"| Q

Worked Example

Assume 1,000,000 active series, each scraped every 15 seconds (a stated design input). Raw points per series per day:

Total raw points/day across the fleet: $1{,}000{,}000 \times 5{,}760 = 5.76\times10^{9}$.

Hot (1 day). Assume time-series-optimized compression achieves roughly 2 bytes/point (a stated assumption for delta-of-delta timestamp and XOR value encoding, not a cited benchmark), plus 30% index overhead:

Warm (30 days). Larger compaction blocks improve the ratio slightly to 1.5 bytes/point, still at full resolution:

Cold (1 year). Downsample to 5-minute resolution, a 300s/15s = 20x reduction in point count, at 2 bytes/point:

Had the cold tier kept raw resolution instead, the year would cost $5.76\times10^{9} \times 365 \times 2\ \text{B} \approx 4{,}204.8\ \text{GB}$, about 20x more, which is the whole reason the downsample step exists.

Archive (years 2 to 7, 6 years). Downsample further to 1-hour resolution (24 samples/day), at 1.5 bytes/point since bulk cold storage compresses better:

Total 7-year footprint (before replication): $15.0 + 259.2 + 210.2 + 78.8 \approx 563.2\ \text{GB}$. Kept at raw resolution for all 7 years instead, the footprint would be roughly $4{,}204.8 \times 7 \approx 29{,}434\ \text{GB} \approx 29.4\ \text{TB}$, about 52x larger. That gap is the entire economic argument for tiering with downsampling rather than tiering on storage class alone.

Trade-offs and Pitfalls

Downsampling is lossy by design: once a cold-tier block collapses 20 raw points into one 5-minute aggregate, you cannot recover the original spikes inside that window. Decide per metric type whether that is acceptable (aggregate SLI counters, usually fine) or not (a metric feeding an anomaly-detection model that needs the raw shape, usually not, and should either stay hot longer or get its own retention policy).

Cross-tier query stitching is a common failure point: a dashboard spanning "last 45 days" crosses the hot/warm boundary and the warm/cold boundary is close by too, and the query planner has to merge full-resolution warm data with 5-minute cold data without a visible discontinuity in the chart. Test this seam explicitly, it is where tiering bugs show up in production, not inside a single tier.

Archive rehydration cost is easy to underestimate: a 1-hour restore-initiation SLA sounds fast until a customer asks for a 3-year lookback across 1,000 series and that pulls thousands of archive blocks, each carrying its own restore latency and egress cost. Expose rehydration as an explicit, rate-limited, customer-visible operation rather than pretending archive queries behave like cold-tier queries.