Datadog platform architecture

1. Overview #

One SaaS platform, several products.

Architecture #

Datadog is a SaaS platform: there is nothing to host on the server side. Data arrives through the agent (installed on hosts and Kubernetes nodes), cloud integrations (reading the AWS, Azure, GCP APIs), SDKs (APM, RUM, mobile) or OpenTelemetry. All products share the same model: timestamped data and tags.

2. Sites and organizations #

Where data lives.

Sites #

Common mistake: The site is chosen when the organization is created and cannot be changed afterwards. For data subject to GDPR, choose EU1 from the start, and set DD_SITE=datadoghq.eu everywhere: an agent configured for the wrong site sends its data into the void.

An organization groups users, data and billing. Large companies use child organizations per entity, attached to a parent organization for billing.

3. Keys #

Securing access.

Keys and tokens #

• One API key per use case (production, staging, CI), so that one can be revoked without breaking everything.
• Application keys inherit their user's permissions: prefer service accounts for automation, with limited scopes.
• The client token is public by nature (it is in the JavaScript code): it only allows sending RUM and browser log data.

4. The data model #

Everything goes through tags.

Unified tagging #

Unified service tagging relies on three reserved tags, set the same way everywhere: env, service, version. They link a metric, a log, a trace and a RUM session of the same service.

Good to know: Each product has its own billing model: the « Costs and governance » article in this course details how to track and control consumption.