System & Data-Modeling Design Overview

Walk into most system design rounds and the first move is a capacity estimate: reads per second, storage per day, how many machines. Palantir starts somewhere else. You are usually handed a vague, high-stakes, real-world situation with messy data behind it, and the graded skill is turning that mess into a model someone can act on. A field commander needs to see where every asset is. An agency wants a knowledge graph over people, places, and events. A hospital wants to fold a dozen record systems into one view that flags readmission risk. The scale that matters is the number of sources you have to reconcile and the rules that govern who can see what.

The Palantir angle

A Palantir design turns heterogeneous, messy data into a governed, semantic model people can operate on, and that framing is the whole differentiator. Integration, modeling, access control, and provenance are the load-bearing parts of almost every prompt, and a strong answer leads with them rather than with throughput. Ground the work in what Palantir builds. Foundry is the commercial data-integration and operations platform. Gotham serves government, defense, and intelligence users. The Ontology is the semantic layer on top of both, connecting raw datasets to the real-world things they describe. If your answer would look the same at a consumer social app, you have missed what this round is checking. Lead with the data model and the governance rules, and the Palantir shape of the design becomes unmistakable.

The two rounds where design shows up

Design signal at Palantir is split across two onsite rounds, and neither is a stock whiteboard exercise. The first is the Decomposition round, which nearly every candidate gets and which many loops turn on. You are given an open-ended problem with no defined scope, no listed inputs, and no obvious solution. Your job is to structure it: clarify the constraints, name the entities and data, decompose it into components, propose a model, and defend the tradeoffs. There is usually little or no code. It is meant to feel like a forward-deployed engineer walking into a customer site for the first time. The second is the System Design round, closer to a conventional high-level design but Palantir-flavored: integrate the sources, model the entities, enforce policy-driven access, and support a real operational decision.

Both rounds share a defining habit, so expect it before you sit down. The interviewer starts you deliberately under-specified, then piles constraints on mid-conversation to watch you adapt. Now it is air-gapped. Now the feed arrives seven days late with new columns. Now these rows are classified and only cleared users may see them. Now un-merge the two entities you just resolved. The round is built to grow, so a design that only works in its first, tidy form falls apart the moment the escalation lands. Each of these rounds also carries roughly twenty minutes of embedded behavioral, since Palantir has no standalone values round and threads mission and ownership questions through the technical work instead.

• Decomposition round: The signature. About 60 minutes, usually on a shared drawing surface, little or no code. A vague real-world prompt you break into entities, data, components, and tradeoffs. Nearly every candidate gets it, and it is where a large share of loops are decided. Jumping to a solution before scoping the ambiguity is the cardinal mistake.
• System Design round: Palantir-flavored HLD. About 45 to 60 minutes. Integrate heterogeneous data, model the entities, enforce policy-driven access, support an operational decision. Correctness, security, auditability, and fault tolerance are graded first-class, not as extras you mention at the end.
• The escalation: Constraints mid-round. Both rounds start under-specified on purpose, then the interviewer adds constraints live: air-gapped, late data with schema drift, newly classified rows, an entity to un-merge. Your design has to grow under pressure rather than break.
• Embedded behavioral: About 20 min per round. There is no separate values round. Mission fit, ownership, and stakeholder judgment are woven into each technical round, so the design conversation shares its time with a real behavioral thread.

Whether you get the System Design round depends on the role and how the loop is composed. Candidates draw three of four rounds from a fixed menu instead of sitting all of them. The Decomposition round is the near-constant. Forward-deployed candidates, who deploy the platforms on a customer's real data, lean hardest on data-wrangling and modeling under ambiguity; platform software engineers, who build the products, see more conventional design depth. The shapes below recur across both.

The shapes you will be asked to model

Palantir does not publish a question list, so read the chart below as an ordering of where prep pays off, not as measured rates. What holds steady is the family of shapes. They cluster tightly around the same idea: take messy data from many places, give it a shared meaning, and govern every step.

The Palantir angle

The Ontology is the concept no other company owns, and modeling it well is the highest-signal move in this section. It is the semantic layer that sits over integrated data and connects it to real-world things, so much so that Palantir describes a mature one as a digital twin of the organization. Two halves matter. The semantic half is what most candidates reach for: object types with properties, and typed links between them, which is a knowledge graph. The kinetic half is what separates a Palantir answer from a generic one: action types, the state-changing operations an operator can take on the model, with validation and side-effects. Naming that objects, links, and actions live together, and that security is a property of the object rather than a check bolted on afterward, reads as someone who understands what Palantir sells. The first worked design builds exactly this.

What the round rewards

The clearest way to score well is to structure the ambiguity before you draw anything. Name the data sources and how messy each one is. Name the users and the decision they are trying to make. Name the sensitivity levels and the legal or operational constraints. Only then start decomposing into components. Candidates who leap straight to boxes and arrows read as skipping the part Palantir cares about most, because in a real deployment the scoping is where the value is. From there, the differentiator is treating governance and provenance as cross-cutting from the first box, not as a slide you add at the end.

The Palantir angle

Governance here is mandatory and it propagates, which is unlike the optional role-based access most designs bolt on. Palantir's data carries markings, and if a resource holds several markings a user needs all of them to see it. Those markings follow the data through every transform via lineage. A derived dataset inherits the markings of its inputs. An export job fails if the data still carries a marking the destination is not cleared for. Classification-based controls add government-grade releasability rules, and purpose-based controls grant access for a declared, auditable reason. The sharpest probe in a governance prompt is whether a marking on a single source column follows the data everywhere and never leaks through an aggregate count. On top of that, assume the system may run on-premise or fully air-gapped, so avoid leaning on any one cloud provider's managed service as if it will always be there.

A prompt you might get

Here is a representative shape, close to the multi-source integration prompt that leads the chart. Read how little is specified on purpose.

A strong opening does not start drawing. It asks what the sources are and how they arrive, and who queries the result for what decision. It asks how sensitive the data is, who is cleared to see it, and how fresh the answers need to be. Then it scopes a defensible first version and names what it is leaving out. Expect the interviewer to escalate once you have that footing: now it is air-gapped, so which parts of your design depend on a managed service that will not be there. Now two source systems disagree about the same person, so how does entity resolution decide, and can you reverse the merge later. The point of the round is to watch the design bend without breaking, so build it to grow.

The worked designs

Five designs follow, one per distinct shape from the chart, each built to carry the integration, modeling, governance, and provenance signature so the set reads unmistakably as Palantir. Start with the Ontology, since it is the concept the other four keep pointing back to.

Each design assumes the fundamentals from the System Design course. That means the scaling playbook for read and write paths, and the toolbox for when to reach for a log, a store, an index, or a queue. These pages stay on the Palantir-flavored modeling and governance and leave the general mechanics to those. Some decomposition prompts carry no fixed architecture at all, like modeling a chess game or a parking garage from scratch. Those live in the coding section alongside the Decomposition round, since they are object-modeling exercises more than distributed-systems designs.