Before any detail, we need a clear picture of the problem and the promise.

A database, but built for the whole planet

Azure Cosmos DB is a fully managed database service on Microsoft Azure. “Fully managed” means Microsoft runs the servers, applies patches, replaces broken hardware, keeps copies of your data, and monitors health. You never log into a machine. You create an account, create a container for your data, and start reading and writing. The service is often described as a NoSQL database, which simply means that it does not force your data into the rigid rows and columns of a traditional relational database. Instead, the most common form stores flexible JSON documents, where each document can have its own shape.

What makes Cosmos DB special is not that it stores JSON. Many systems do. It is special because of a bundle of promises that are very hard to deliver together: single-digit millisecond response times at the 99th percentile for ordinary reads and writes, elastic scaling in both storage and throughput, replication to any number of Azure regions with a click, multiple choices for how fresh your reads must be, automatic indexing, and published availability guarantees of up to 99.999 percent for multi-region accounts.

The problems it was designed to solve

Modern applications face three hard problems at once. First, users are everywhere, and distance creates delay because even light takes time to cross an ocean. Second, traffic is unpredictable: a shopping site may be quiet on Tuesday and overwhelmed on a sale day. Third, schemas change constantly because products evolve every week. Cosmos DB answers these with global distribution, elastic throughput, and schema-agnostic storage.

Where Cosmos DB fits and where it does not

Cosmos DB shines for workloads with high volume, many users, global reach, flexible data shapes, and a need for predictable low latency. Examples include shopping carts, user profiles, gaming leaderboards, device telemetry, personalization, order tracking and metadata stores for AI applications. It is a weaker choice for heavy multi-table reporting with complex joins, for ad hoc analytics scanning entire datasets, or for a small single-region application that a plain relational database would serve at a fraction of the cost. Knowing when not to use it is part of expertise.

Cosmos DB speaks several database “languages”, and choosing the right one early matters.

An API in this context is the set of commands and protocols your application uses to talk to the database. Cosmos DB offers several, and the choice is made when you create the account. You generally cannot change it afterwards, so it deserves care.

How to choose

If you are building something new, the NoSQL API is usually the best choice because it is the most complete and the most actively improved. If you are migrating an existing application that already uses MongoDB or Cassandra drivers, the matching compatible API lets you move with minimal code changes. Be honest about compatibility: a compatible API implements a large portion of the original behavior, but not everything. Always test your real workload and check the list of supported features before committing.

The rest of this guide focuses on the NoSQL API concepts, because nearly all of the core ideas such as Request Units, partitioning, consistency and global distribution apply across the family in some form.

Every Cosmos DB design starts from a four-level hierarchy.

flowchart TD
  A["Azure Subscription"] --> B["Cosmos DB Account"]
  B --> C["Database"]
  C --> D["Container"]
  D --> E["Items"]
  B --> F["Region list and default consistency"]
  D --> G["Partition key, indexing policy, TTL, unique keys"]
        

Why the container is the star

Beginners from relational backgrounds often create one container per entity type, mimicking tables. That habit is expensive. Because throughput, partitioning and indexing all attach to containers, many small containers each provisioned separately can waste money, and cross-container operations cannot be done in one transaction. Experienced designers frequently place several related item types into one container, distinguishing them with a type property, so that related data shares a partition and can be read together.

Identity of an item

An item is uniquely identified by the pair of its partition key value and its id. This pair is the fastest possible way to reach it, called a point read. Remember this pair; it will keep returning in later chapters because it is the heart of cheap, fast access.

You do not pay for CPU, memory or disk operations separately. You pay in one blended unit.

A Request Unit, usually written RU, is an abstract measure of the resources an operation consumes: processor time, memory and input and output work, all rolled into one number. The service tells you the RU charge of every operation in the response. This simplicity is powerful, because you can predict cost from design rather than guess from hardware.

Rules of thumb that every designer memorizes

The anchor point is that reading a 1 KB item by its id and partition key costs about 1 RU. Writing a similar item costs several times more, commonly around five or more, because the write must be replicated and indexed. Queries cost depending on how many items they scan, how many they return, how many index entries they use and whether they cross partitions. Larger items cost more. More indexed properties cost more on writes. Stronger consistency costs more on reads.

What happens when you exceed your budget

Throughput is expressed as RU per second. If your requests need more than you have provisioned in a given second, the service rejects the extra with an HTTP 429 response, politely named “request rate too large”, and tells the client how long to wait before retrying. Official client libraries retry automatically a limited number of times. A few 429s are normal and healthy at high utilization. Many sustained 429s mean the container is undersized or, more often, that one partition is overloaded while others sit idle, which is a design flaw we will examine later.

Why RUs make capacity planning possible

Because every operation has a measurable RU cost, you can estimate needs with simple arithmetic: expected reads per second times their cost, plus writes per second times theirs, plus queries. Teams that skip this exercise often discover surprise bills. Teams that practice it can compare design alternatives, such as embedding versus referencing, by their RU impact before writing production code.

One idea explains almost all of Cosmos DB’s speed and almost all of its pitfalls.

A single machine can only hold so much data and serve so many requests. To go beyond that, Cosmos DB splits a container into pieces and spreads them across many machines. This is called horizontal partitioning, or sharding. The service uses the partition key, a property you choose when you create the container, to decide which piece each item belongs to. The key’s value is passed through a hash function, which turns it into a number that decides placement.

graph TD
  I["Items with partition key values"] --> H["Hash of partition key value"]
  H --> L1["Logical partition: customer A"]
  H --> L2["Logical partition: customer B"]
  H --> L3["Logical partition: customer C"]
  H --> L4["Logical partition: customer D"]
  L1 --> P1["Physical partition 1"]
  L2 --> P1
  L3 --> P2["Physical partition 2"]
  L4 --> P2
        

Automatic splits and the throughput consequence

When a physical partition grows beyond its storage limit, or when its share of throughput would exceed its limit, the service splits it into two, moving data in the background without downtime. Here is the subtle part: the throughput you provision for a container is divided evenly among its physical partitions. If you provision 30,000 RU/s and the container has three physical partitions, each can use about 10,000 RU/s. If all of your traffic hits one partition, you are limited to that partition’s share, and you may be throttled while the other two partitions are idle and the bill continues.

Partition key choices are mostly permanent

You choose the partition key when creating the container, and changing it later means creating a new container and copying data. Tools and features exist to help with such migrations, but they are projects, not toggles. This is why the next chapter, on choosing a key, is the most important design decision in the whole guide.

A good key spreads data and traffic evenly and lets your most common queries stay inside one partition.

Three qualities define a good partition key. First, high cardinality: many distinct values, so that data can spread across many logical partitions. Second, even distribution of both storage and request volume across those values. Third, alignment with your most frequent queries so that they carry the key in their filter and are served by a single partition. A key that fails the first two causes hot partitions. A key that fails the third causes expensive cross-partition fan-out.

flowchart TD
  A["List your top queries and writes"] --> B["Find the property most queries filter on"]
  B --> C{"Many distinct values?"}
  C -->|No| D["Consider a synthetic or hierarchical key"]
  C -->|Yes| E{"Traffic spread evenly across values?"}
  E -->|No| D
  E -->|Yes| F{"Each value stays under 20 GB?"}
  F -->|No| D
  F -->|Yes| G["Strong candidate key"]
        

Examples of good and bad keys

Synthetic keys

When no single property works, you can build a synthetic key by combining properties, for example joining a tenant id with a month, or adding a small number suffix to spread a very busy value across several partitions. The trade-off is that queries now need to know how the key is composed, and spreading one value over several partitions means reading them all to see everything for that value.

Hierarchical partition keys

Hierarchical partition keys let you define up to three levels, such as tenant, then user, then session. The service treats the combination as the key while allowing queries that supply only the first level or two to be routed to a targeted subset of partitions instead of everything. They also help overcome the 20 GB limit for a single large tenant, because that tenant’s data can spread across sub-levels. For multi-tenant systems with one giant customer and many small ones, this feature can solve a problem that was once painful.

Three ways to pay for capacity, each fitting a different traffic personality.

Dedicated versus shared throughput

You can provision throughput on a single container, giving it guaranteed capacity, or on a database so that its containers share a pool. Shared throughput is economical for many lightly used containers, but one noisy container can consume the pool and starve the others, and you cannot guarantee any single container a minimum. Many production teams use dedicated throughput for important containers and a shared pool only for small supporting ones.

Burst capacity and right-sizing

The service can allow short bursts above provisioned throughput by using idle capacity accumulated in recent seconds, which helps with brief spikes. It should be seen as a safety margin, not a plan. For sizing, watch the normalized RU consumption metric: if the busiest partition is consistently near one hundred percent while the account average is low, you have a distribution problem, not a capacity problem, and buying more RU/s will not solve it.

The biggest mindset shift from relational databases is that you design for your questions, not for purity.

In a relational database you normalize: break data into many tables to avoid repetition, then join them at read time. Joins across machines are expensive in a distributed system, so Cosmos DB encourages the opposite for data that is read together: put it inside one document. This is called embedding or denormalization. The alternative, keeping separate documents and storing the id of one inside the other, is called referencing.

A decision guide

Embed when the related data is read together, changes together, is bounded in size, and rarely changes independently. A customer’s shipping addresses, or the line items of an order, are classic examples. Reference when the related data grows without limit, is shared by many parents, changes frequently on its own, or is rarely needed with the parent. A product’s thousands of reviews, or a blog post’s unlimited comments, should be separate items.

Mixing item types in one container

A powerful pattern is to store a customer and its orders as different item types in the same container, all sharing the customer id as the partition key. A single query on that key can then return both, and everything for one customer lives together on one partition. A type property tells the application which shape it is reading. This gives some of the convenience of joins without cross-partition cost.

By default, Cosmos DB indexes everything. That is a gift and a cost.

An index is a separate structure that lets the database find items without examining every one, just like the index at the back of a book lets you find a topic without reading every page. In many databases you must create indexes by hand and forget to. In Cosmos DB, every property of every item is indexed automatically by default, with no schema or manual effort. The engine does this by converting each item into a tree of paths and values and indexing those paths. This is why you can query on any property from day one.

The indexing policy

Each container has an indexing policy that controls what is indexed. You can include or exclude specific paths, choose the indexing mode, and add special indexes for particular needs.

Why tune it

Every indexed path adds work to each write, increasing RU cost and storage. If your documents have fifty properties but you only ever filter on three, indexing the other forty-seven is waste. A common production approach is to exclude everything by default and include only the paths used in filters and sorts. For write-heavy workloads with large documents, this change alone can cut the cost of writes dramatically.

Indexing modes and consistency of the index

In the standard mode, the index is updated as part of each write so queries immediately reflect new data. An option to turn indexing off exists for containers used only for point reads by id, where no queries are needed, which makes writes cheaper still. Changes to the policy are applied in the background by re-indexing, which consumes spare throughput and may take time on large containers, so plan changes for quieter periods.

Understand what a query does under the hood and you can predict what it will cost.

The NoSQL API uses a query language that resembles standard SQL, with filters, projections, sorting, aggregates and grouping, plus operators for working with arrays and nested objects. It does not support arbitrary joins across containers. A join in this language means combining an item with its own embedded arrays, which stays inside one item and one partition.

sequenceDiagram
  participant App as Application
  participant SDK as Client library
  participant GW as Routing layer
  participant P1 as Partition 1
  participant P2 as Partition 2
  App->>SDK: Query with partition key
  SDK->>GW: Route to one partition
  GW->>P1: Execute using index
  P1-->>App: Results and RU charge
  App->>SDK: Query without partition key
  SDK->>GW: Fan out to all partitions
  GW->>P1: Execute
  GW->>P2: Execute
  P1-->>SDK: Partial results
  P2-->>SDK: Partial results
  SDK-->>App: Merged results and total RU charge
        

The cost levers of a query

Query metrics

Responses can include metrics describing how many items were scanned versus returned, index lookup time, and where the time went. A healthy query scans roughly as many items as it returns. A large gap between scanned and returned, a “scan to result ratio”, signals a missing or unusable index. Make reviewing these numbers a regular habit for your ten most expensive queries.

A distributed database must answer one awkward question: when I write in one place, when will others see it?

When data is copied across machines and regions, copies cannot all update at the exact same instant. There is a trade-off between how fresh your reads are, how fast they are, how much they cost, and how available the system stays during problems. Many databases offer only two choices: strict or loose. Cosmos DB offers five well-defined points along a spectrum, so you can match the guarantee to the need.

graph LR
  A["Strong"] --> B["Bounded Staleness"]
  B --> C["Session"]
  C --> D["Consistent Prefix"]
  D --> E["Eventual"]
        

Cost and performance implications

Stronger levels need more coordination between replicas, so reads under strong or bounded staleness consume roughly double the RUs of the weaker levels. In multi-region setups, strong consistency adds the round-trip time between regions to the write path, which is why it is often impractical across continents. The default session level hits the sweet spot for most applications: users see their own actions instantly, and the system stays fast and cheap.

Relaxing consistency per request

The account has a default level, but an individual request can ask for a weaker level than the default, never a stronger one. That means an application can keep a conservative default and relax it for read-heavy, low-risk screens like a product catalog browse.

Session tokens in practice

Session consistency works by passing a small token between the client and the service that records how far the client has seen. If your application is spread over many servers behind a load balancer, a user’s second request may land on a different server that lacks the token. For flows that need strict read-your-writes across servers, the application must carry the token along, for example inside the user’s own request state. Forgetting this is a classic source of confusing “my update vanished” reports.

Adding a region is a configuration change, not a migration project.

You can associate an account with any number of Azure regions, and the service replicates your data to each automatically. Applications then read from the region closest to them, cutting latency. There are two modes of operation. In single-write-region mode, one region accepts writes and the rest serve reads. In multi-region writes mode, every region accepts both reads and writes, giving users in every continent fast writes and a higher availability target.

flowchart LR
  U1["Users in Asia"] --> R1["Region: Central India"]
  U2["Users in Europe"] --> R2["Region: North Europe"]
  U3["Users in Americas"] --> R3["Region: East US"]
  R1  R2
  R2  R3
  R1  R3
        

Conflicts and how they are resolved

If two users in different regions change the same item at nearly the same moment, a conflict occurs. The default policy is last writer wins, based on a timestamp property that the system maintains, so the later change quietly replaces the earlier one. You can instead choose a custom numeric property as the deciding value, or choose a policy that records conflicts into a feed so that your own code can inspect and merge them. For most applications the best approach is to avoid conflicts by design, for example by making each user “belong” to a home region for writes or by partitioning data so that a given item is normally written from one place.

Failover and region priority

Regions have a priority order. If the write region becomes unavailable in a single-write setup, the service can fail over automatically to the next region in the list. Clients using the official libraries are told about the region list and redirect themselves, and you can set a preferred read order so that each application instance reads from the nearest healthy region. Rehearse failover in a test environment; teams that never practice often discover assumptions in their code only in a real outage.

Availability is how often the service answers. Durability is whether your data survives. Backup is the last line of defense.

Layers of protection

Inside a single region, every physical partition is stored as a replica set of several copies, so a failed machine is invisible. With availability zones enabled, those copies are spread across physically separate buildings, each with independent power and cooling, so even the loss of a whole zone does not interrupt service. Across regions, geo-replication protects against regional disasters. Each added layer raises the availability the service promises, from 99.99 percent for a single region, a little higher with zones, up to 99.999 percent for multi-region accounts.

Backup modes

Recovery thinking

Two numbers define a recovery plan: how much data you can afford to lose, and how long you can afford to be down. Multi-region accounts with automatic failover tend to give very small data loss windows and short downtime for region failures. For accidental deletion, only a point-in-time restore helps, and restores go into a new account, so rehearse the steps of switching your application to it. Document who is allowed to trigger it and how long it takes.

Every create and update is quietly recorded, ready for you to react to.

The change feed is a persistent, ordered record of changes made to the items in a container. Rather than polling “has anything changed?”, your code reads the feed and receives each change exactly as it arrived. It is built in, requires no setup, and does not slow normal operations. Order is guaranteed within a single partition key value, not across the whole container.

flowchart LR
  A["Application writes items"] --> B["Container"]
  B --> C["Change feed"]
  C --> D["Change feed processor"]
  D --> E["Search index update"]
  D --> F["Message bus event"]
  D --> G["Materialized view container"]
  D --> H["Analytics pipeline"]
        

What teams use it for

Processing at scale

The change feed processor library coordinates multiple workers reading in parallel. It stores its progress in a small separate container called the leases container, so that if a worker crashes, another resumes from where it stopped. Delivery is at least once, which means a change may be delivered more than once after a failure. Your handlers must therefore be idempotent, meaning that running them twice has the same effect as running once.

Modes and limits

The classic mode shows the latest version of each changed item and does not directly report deletions. A common workaround is soft delete: mark an item as deleted and let time-to-live remove it later, so the change is visible. A newer mode, available with continuous backup, can expose all versions of an item and deletions, giving a fuller history. Pick the mode that matches what your consumers need to know.

Correctness features exist, but they live inside the boundary of a single logical partition.

Transactions within a partition

Cosmos DB provides ACID transactions, meaning operations that are atomic, consistent, isolated and durable, for items that share the same partition key value. A transactional batch lets you submit several operations on items in one partition and have them all succeed or all fail together. Stored procedures, written in JavaScript and run inside the database next to the data, offer the same guarantee with custom logic. There is no cross-partition ACID transaction. If your business rule spans partitions, you design for it with patterns like the saga: a sequence of local steps, each with a compensating action to undo it if a later step fails.

Optimistic concurrency

Every item carries an entity tag, called an ETag, that changes with each update. When you update, you can ask the service to apply your change only if the tag still matches what you read. If someone else changed the item in the meantime, your update is refused and you can re-read and try again. This prevents the “lost update” problem without locking.

Time to live

Time to live, or TTL, automatically deletes items after a set number of seconds. You can set a default on the container and override it on individual items. It is ideal for sessions, temporary tokens, caches and log data. Expired items stop appearing in queries promptly, and the physical removal runs in the background using spare throughput, which means it never competes with your live traffic but may lag when the container is very busy.

Unique keys

A unique key constraint ensures that no two items in the same logical partition share the same value for a chosen property, such as an email address within a tenant. It is enforced per partition, not across the entire container. Two different partition key values may legally hold the same unique property value, so for global uniqueness you must make the partition key and the unique property line up or enforce uniqueness another way.

Two features that add speed and analytics without disturbing your live workload.

Integrated cache

A dedicated gateway is a set of managed nodes that sit between your application and the database. When enabled, it contains an in-memory cache for point reads and queries. Repeated reads of the same data are served from memory and cost no RUs at all, which is dramatic for read-heavy applications with hot data. The cache applies to reads at session or eventual consistency, and you control how stale a cached answer may be by setting a maximum age.

Analytical store and mirroring

Running a large analytical query against the transactional store competes with your application’s reads and writes and burns RUs. The analytical store solves this by keeping a separate, automatically synchronized, column-oriented copy of your data optimized for scans and aggregates. Because it is separate, analytics do not consume your provisioned throughput. Services such as Azure Synapse can query it directly through a feature known as Synapse Link. Mirroring into Microsoft Fabric follows a related idea, continuously replicating operational data into open analytical storage where reporting and machine learning tools can use it without writing your own pipelines.

Modern AI applications need to find data by meaning, not just by exact match.

An embedding is a long list of numbers produced by an AI model that captures the meaning of a piece of text, an image or other content. Items with similar meaning end up with numbers that are close together. Vector search finds the items whose embeddings are nearest to the embedding of a question. This powers semantic search, recommendations and retrieval-augmented generation, where an AI assistant first retrieves relevant facts from your data and then writes an answer grounded in them.

Why store vectors beside operational data

Cosmos DB for NoSQL can hold embeddings inside the same items as the rest of your data and index them with a dedicated vector index. This avoids operating a separate vector database and keeping it synchronized. Filters on ordinary properties, such as tenant or category, can be combined with the similarity search, so a multi-tenant application returns only the caller’s own data. Several index approaches are offered, from exact comparison suitable for small sets to approximate approaches built for very large sets, including one derived from a disk-based graph method for high scale at lower memory cost.

Design cautions for vector workloads

Embeddings are large, so items with vectors are bigger and cost more RUs to write and read. Exclude the vector path from the normal range index, since it must use the vector index instead. Keep an eye on the dimensions of the embeddings, because they affect storage and query cost. When the embedding model changes, the stored vectors must be regenerated, so keep the source text and a model version marker alongside each vector. Publicly, Microsoft has described Cosmos DB as part of the data layer behind very large AI services, which shows the engine is meant to carry such loads.

Treat the database as the vault of the business and secure it in layers.

Identity and access

Historically, applications connected with account keys, which are powerful shared secrets that grant broad access. The modern approach is to use Microsoft Entra ID with role-based access control, where each application or person receives a precisely scoped role, such as read-only on one database. Applications running in Azure use a managed identity, so no secret is stored in code or configuration at all. A strong production stance is to disable key-based access entirely once all clients have moved to identities, so that a leaked key becomes impossible.

Network protection

Encryption and sensitive fields

Data is encrypted at rest by default with keys managed by the service, and all connections use encrypted transport. Organizations with stricter rules can bring their own key, stored in a key vault, and control rotation and revocation. For especially sensitive fields such as national identifiers or health values, client-side encryption lets the application encrypt a property before it is ever sent, so the service itself never sees it in plain form. The trade-off is that the database cannot filter or index freely on encrypted values, so the design must account for that.

You cannot tune what you cannot see.

Cosmos DB reports metrics and logs through Azure Monitor. A well-run team builds a small dashboard and a few alerts early, rather than after the first incident. The metrics below tell most of the story.

A troubleshooting routine

A well-designed Cosmos DB account can be reasonable; a careless one can be shocking.

Your bill is made up mainly of provisioned or consumed throughput, stored data, extra regions, backup beyond the included amount, and optional components such as the dedicated gateway and the analytical store. Because several of these multiply with each region, geographic reach is a real cost decision, not just a technical one.

Free and trial options

A free tier grants a monthly allowance of throughput and storage on one account per subscription, which suits learning and small projects. Remember that deleting a container or the account is the only way to truly stop all charges in a learning environment, so clean up when you finish experimenting.

Patterns are proven recipes; anti-patterns are proven ways to hurt yourself.

Patterns worth knowing

Anti-patterns to avoid

A short list to review before every production launch.

A closing habit that separates seasoned teams from beginners: run a load test with realistic data volume and realistic key distribution before launch, and read the RU charges and partition metrics during that test. Problems found in a test cost an afternoon; problems found in production cost a weekend and a reputation.

The same building blocks appear again and again across industries.

Quick answers to the questions that come up most often.

No. The NoSQL API stores flexible documents and scales out by splitting data into partitions. It does not offer arbitrary joins across containers or cross-partition transactions. It trades some relational conveniences for scale, low latency and global reach.

Not in place. Changing it means creating a new container with the desired key and migrating the data, which is a planned project. That is why the choice deserves careful analysis at the start.

Throughput is divided among physical partitions. If one partition receives far more traffic than the others, it can hit its share while the rest are idle. Check the busiest-partition utilization and the key distribution.

Session is the sensible default for most applications because users see their own changes and cost stays low. Choose stronger levels only for a proven business need, and weaker levels for non-critical, high-volume reads.

An RU is a blended measure of processor, memory and input and output work required for an operation. It lets you reason about cost and capacity with one number instead of several hardware figures.

Under weaker consistency levels, replication to other regions happens in the background and does not hold up the write. Under strong consistency, the write must be confirmed across regions, so distance adds to latency.

With multi-region writes, a conflict resolution policy decides. By default the later timestamp wins. You can choose a custom deciding property or capture conflicts for your own code to resolve.

Not to get started, because everything is indexed by default. For production, tune the policy so that only needed paths are indexed, and add composite indexes for multi-property sorting or filtering.

Yes, by using the analytical store or mirroring, which keep a separate columnar copy synchronized automatically, so scans do not consume your transactional throughput.

It can be for light or sporadic production workloads, but it has lower scale limits and has historically been restricted to a single region. Verify the current limits against your needs before relying on it.

Use continuous backup to enable point-in-time restore, restrict delete permissions through role-based access, and consider soft-delete patterns in your application. Replication alone will not protect you.

Yes. You can store embeddings in items, index them with a vector index, add full-text indexing, and combine them for hybrid search. This lets you retrieve relevant context for AI assistants from the same database that holds your operational data.

Treating it like a relational database: many containers, normalized data, and queries without the partition key. Start from access patterns and the partition key, and most other decisions fall into place.

Azure Cosmos DB gives you a planet-scale, fully managed database with predictable low latency, elastic capacity, and a menu of consistency choices. Its power comes from a small set of ideas that work together: data is split by partition key into partitions that spread across machines, work is priced in Request Units, every property is indexed unless you say otherwise, copies live in many regions, and a change feed turns every write into an event. If you remember only one thing, remember that the design choices made at the start, especially the partition key and the data model, determine the speed, the reliability and the cost for the entire life of the system. Understand those, measure often, and the service rewards you with a platform that grows as far as your ambitions do.