Snowflake·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jun 2026

Summary

Snowflake system design round, one big question that sprawled in every direction. The scope was way larger than I expected and I spent too long on the easy parts before realizing I hadn't touched half the requirements.

Questions Asked (1)

Design a caching strategy for a materialized view system where views are organized as a DAG with dependencies on each other. Cover what to cache, where to cache it, cache key design and versioning, eviction, freshness guarantees, and how to handle invalidation when base data changes. Also explain how updates propagate through the DAG, how you'd deal with partial failures and backfills, hot key problems, and how you'd monitor correctness and performance.

System DesignTechnical Trade-offsData Modeling

Author's notes

I started with the easy stuff, in-memory vs disk vs distributed, and burned maybe 10 minutes on that before the interviewer nudged me toward the DAG propagation piece, which was clearly the heart of it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a layered caching architecture that aligns with the DAG structure, covering cache placement, key design, invalidation, and failure handling. Emphasize trade-offs between consistency, freshness, and performance, and discuss monitoring and operational aspects.

Pro tip: Highlight the importance of versioning and idempotency in cache keys to handle backfills and partial failures gracefully, and mention how Snowflake's architecture (e.g., separation of storage and compute) could influence caching decisions.

1. Clarify Requirements and Constraints

Ask about freshness SLAs, data volume, update frequency, and consistency requirements to tailor the caching strategy.

2. Design Cache Placement and Key Structure

Decide what to cache (materialized view results, intermediate results) and where (in-memory, local disk, distributed cache), and define cache keys incorporating view ID, version, and parameters.

3. Define Invalidation and Propagation Strategy

Explain how base data changes trigger invalidation and how updates propagate through the DAG, including handling of partial failures and backfills.

4. Address Eviction, Hot Keys, and Freshness Guarantees

Discuss eviction policies (LRU, TTL), strategies for hot keys (replication, sharding), and how to provide freshness guarantees (e.g., time-based, version-based).

5. Monitor Correctness and Performance

Outline metrics for cache hit ratio, latency, staleness, and error rates, and describe how to detect and recover from inconsistencies.

Key Points to Mention

Cache key design: include view ID, version, and query parameters; use hashing for compactness.
Versioning: use monotonically increasing version numbers or timestamps to invalidate stale entries.
Invalidation: propagate changes through the DAG using a dependency graph; consider push vs. pull models.
Partial failures: implement retries, idempotent updates, and transactional guarantees where possible.
Hot keys: mitigate with replication, sharding, or local caching at compute nodes.
Monitoring: track cache hit/miss, latency, staleness, and correctness via checksums or reconciliation.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.