All jobs / Solutions / cloud architect
Data Architecture interview questions
Data Architecture questions a Solutions / cloud architect can be asked, from first job to senior. Open one to see the strongest answer and why it works.
When does adding a cache make sense, and what is the first question to ask?
The strongest answer: When the same read is repeated and the source is slow or expensive; the first question is how stale the data may be
Why it works: Exactly. Repeated reads, expensive source, and a staleness budget you can name before you build.
- Repeated reads of an expensive source.
- Ask how stale is acceptable.
- A cache is a copy; copies drift.
- Not a substitute for the store.
Why not run the analytics dashboards directly against the production database?
The strongest answer: Analytics scans large ranges and aggregates while production does many small transactions; they compete for the same resources and the schema suits only one of them — copy the data to a replica or a warehouse shaped for analysis
Why it works: Exactly — different workloads, different schema, different store; separate them.
- Separate transactional from analytical.
- Different workloads compete.
- Replica or warehouse for analysis.
- Schema shaped for the questions.
A team asks whether to use SQL or NoSQL for a new service. What is your first question back?
The strongest answer: What are the access patterns and how important are relationships and transactions — the data shape and the queries decide it, not the fashion
Why it works: Exactly. Queries and consistency needs first; volume and skill follow.
- Ask about queries and relationships.
- Transactions needed or not?
- Volume and skill come second.
- “Faster” is meaningless alone.
What does CAP actually mean for a design decision, in plain terms?
The strongest answer: When the network partitions, each part of the system either refuses some requests to stay consistent or answers with possibly stale data to stay available — you choose per operation, not per system
Why it works: Exactly. Partition is the given; the choice is what each operation does when it happens.
- Partitions happen; that is the given.
- Refuse (consistent) or answer stale (available).
- Choose per operation.
- No product “solves” it.
How do you keep a cache honest when the underlying data changes?
The strongest answer: Set a TTL as the safety net, invalidate or update on write for the keys you know changed, and accept a stated staleness window rather than promising zero
Why it works: Exactly. TTL as a floor, targeted invalidation on write, honesty about the window.
- TTL is the safety net.
- Invalidate the keys you changed.
- State the staleness window.
- No full flushes, no 2PC to a cache.
Where can caching sit in a web system, and how do you decide which layer to use?
The strongest answer: Browser, CDN, gateway, application memory, a shared cache and the database itself; put it as close to the user as the data’s sharing and freshness allow
Why it works: Exactly. Several layers, each with a scope; the closer to the user, the more you save and the harder freshness gets.
- Many layers, browser to database.
- Closer to the user saves more.
- Sharing and freshness set the layer.
- Every layer needs an owner.
What are the main ways to isolate tenants in a SaaS data layer, and how do you choose?
The strongest answer: Shared schema with a tenant column, schema per tenant, or database per tenant; choose by isolation and compliance needs, tenant count and how uneven the tenants are, not by what is easiest today
Why it works: Exactly. Three models, chosen against isolation, count and skew — and often mixed for large tenants.
- Shared column, schema, or database per tenant.
- Isolation and compliance first.
- Tenant count and skew second.
- One deliberate model, with exceptions written down.
Synchronous or asynchronous replication for the primary database — what does each cost you?
The strongest answer: Synchronous gives a replica with every committed write, so failover loses nothing, at the price of write latency and dependence on the replica’s health; asynchronous keeps writes fast but can lose the last writes and serves stale reads
Why it works: Right — durability and freshness against latency and coupling; the recovery point objective decides.
- Durability versus write latency.
- Sync: no loss, slower writes.
- Async: fast, may lose the tail.
- Let the RPO decide.
The e-commerce team is expanding from one country to four continents.
Product wants globally consistent inventory counts and sub-second responses from every continent. What do you say?
The strongest answer: Those pull against each other; propose strong consistency on the reserve-and-purchase path and a slightly lagging count on display, and show the cost of each alternative
Why it works: Exactly. Split the requirement by operation and make the cost of each visible.
- Name the tension out loud.
- Strong consistency where money moves.
- Lag allowed on display.
- Show the cost of each option.
If an attacker gets administrator access to the production cloud account, do you still have backups? Design so the answer is yes.
The strongest answer: Copy backups to a separate account with different credentials, make them immutable for the retention period, keep point-in-time logs, encrypt them with keys the production role cannot delete, and rehearse the restore
Why it works: Exactly — the backup must live outside the blast radius of the account it protects.
- Backups outside the blast radius.
- Separate account, separate credentials.
- Immutable for the retention period.
- Rehearse the restore.
How do you rename a heavily used database column without downtime?
The strongest answer: Expand and contract: add the new column, write to both, backfill, switch reads, stop writing the old one, then drop it — each step deployed separately and reversible
Why it works: Exactly. Expand, dual-write, backfill, switch, contract. Each step can roll back.
- Expand: add the new column.
- Dual-write and backfill.
- Switch reads, then writes.
- Contract: drop the old one.
The service has no users yet; the team argues it is easier to start with the right stores than to migrate later.
A team proposes a document store, a graph database and a search engine for one new service. What do you say?
The strongest answer: Each store must earn its place with an access pattern the others cannot serve; every extra store adds operations, backup, consistency and expertise costs — start with one primary store and add a specialised one when the pattern is proven
Why it works: Right — polyglot persistence is a cost you take on deliberately, per proven need.
- Every store earns its place.
- Name the access pattern each serves.
- Count the operational cost.
- One primary; specialise when proven.
Finance, sales and product each report a different monthly active-user number to the board.
Every team has its own analytics copy and the numbers never agree. Central warehouse or federated ownership?
The strongest answer: Federate ownership of the source data with shared definitions, contracts and a discovery layer; centralise the definitions and the platform, not the people — a warehouse owned by one team recreates the bottleneck that caused the copies
Why it works: Exactly. Owned data, shared definitions, common platform. Governance is the centralised part.
- Teams own their source data.
- Shared definitions and contracts.
- Common platform and discovery.
- Centralise governance, not people.