Snowflake Architect

An architecture is a path data takes. You map sources, volumes and latency needs, choose layers and where transformation happens, and design for the people and applications at the end of the flow.

• Mapping sources, volumes and latency needs
• Layered models: raw, refined and curated
• Batch, micro-batch and streaming paths compared
• Choosing where transformation happens
• Designing for BI, applications and data science
• Recording the flow as a decision record

You build A source-to-consumption design for a multi-source company, with every choice explained.

Each source has a better way in. You weigh bulk loading, Snowpipe and streaming ingestion, decide when to leave data in place as external or Iceberg tables, and choose between streams and tasks, dynamic tables and external tools.

• Bulk loading, Snowpipe and Snowpipe Streaming
• Connector-based and Kafka ingestion
• External and Iceberg tables for data left in place
• Streams and tasks against dynamic tables
• Transformation in SQL, Snowpark and external tools
• Idempotence and replay by design

You build An ingestion design for three source types, each with its reason and failure plan.

Structure is hard to change after launch. You decide between one account and many, separate environments, build a role hierarchy that matches how teams own data, and treat cost allocation as a design input.

• Single-account and multi-account strategies
• Separating environments and business units
• Functional roles, access roles and database roles
• Managed access schemas and ownership
• Mapping data domains to teams
• Cost allocation as a design input

You build An account and role design for a company with separate business units.

Security is a set of linked decisions. You choose federated sign-in and multi-factor rules, restrict networks and use private connectivity, work with the key hierarchy and customer-managed keys, and test the design against a threat model.

• Federated sign-in, MFA and provisioning
• Network policies and private connectivity
• Key hierarchy, rotation and customer-managed keys
• Service identities and programmatic access
• Securing data movement in and out
• Reviewing a design against a threat model

You build A security architecture for a company with strict network and key requirements.

A regulation is a requirement until you turn it into controls. You translate duties into classification, masking and row access policies, choose regions for residency, and plan the audit evidence the design will produce.

• Translating a regulation into concrete controls
• Classification and tagging of sensitive data
• Masking and row access policies
• Aggregation and projection policies
• Data residency and region choice
• Audit evidence and retention

You build A control matrix mapping three compliance requirements to Snowflake features.

Every tool choice has a performance and cost effect. You design warehouses for workload isolation, decide when clustering, search optimization or acceleration pay off, and choose third-party tools by what they add.

• Warehouse design: sizes, multi-cluster and isolation
• Clustering keys and when they pay off
• Search optimization and query acceleration
• Materialized views, dynamic tables and result reuse
• Third-party tools for ingestion, transformation and BI
• Benchmarking a design before committing

You build A tool and performance comparison for one workload, with measured trade-offs.

A good design survives bad days. You set recovery objectives, lay out replication and failover groups across regions or clouds, use Time Travel and cloning for smaller mistakes, and rehearse the plan.

• Recovery time and recovery point objectives
• Database and account replication
• Failover groups and client redirect
• Time Travel, Fail-safe and cloning for recovery
• Cross-region and cross-cloud designs
• Testing a failover plan

You build A continuity design with objectives, a replication layout and a failover test plan.

Sharing turns a data set into a product. You design secure shares and reader accounts, publish listings on the Marketplace or a private exchange, and plan contracts, refresh and support so consumers can rely on what they get.

• Secure shares and what a consumer can see
• Reader accounts for consumers without Snowflake
• Listings, the Marketplace and private exchanges
• Data Exchange for a defined group of partners
• Designing a data product: contract, refresh and support
• Governance and cost of sharing
• Sharing across regions and clouds

You build A shared data set design with a listing, access controls and a refresh plan.

You are handed requirements for a regulated, multi-team platform. You design the flow, accounts, security, performance, resilience and sharing, then present the architecture and answer a review panel’s objections.

• Reading requirements and finding the conflicts
• Designing flow, accounts and roles together
• Applying security, compliance and resilience
• Weighing cost and performance trade-offs
• Presenting and defending the architecture

You build A full architecture document for a regulated platform, with a decision record per choice.