Data Plane Pump

How Tyk Dashboard gets its analytics data when the control plane and data plane(s) are separate, connected via Tyk MDCB, and what the aggregated analytics setting does and does not affect.

In a distributed deployment, the control plane and one or more data planes run separately, often in different regions or clouds, connected via Tyk MDCB. This changes how traffic data reaches Tyk Dashboard’s persistent database: instead of Tyk Pump writing directly to MongoDB or SQL, as it does when the control and data planes are combined, a Data Plane Pump (type: hybrid) on each data plane is used to forward the data to Tyk MDCB on the control plane, which then writes it to the Control Plane’s persistent database.

​

Why a Separate Pump Process

Tyk Gateway writes traffic logs to its own local Redis, which is not reachable from the control plane. Tyk MDCB never reaches into a data plane’s Redis itself. It only receives data pushed to it over the RPC connection Gateways already use for configuration synchronization.

The Hybrid Pump is a Tyk Pump instance, configured with type: hybrid, deployed alongside your data plane Gateways. It reads traffic logs from the local Redis and forwards them, individually or as aggregated analytics, to Tyk MDCB, the same role Tyk Pump plays when the control and data planes are combined, adapted for a deployment where they’re separate.

Tyk Gateway also has a legacy built-in mechanism for this, enabled with analytics_config.type: rpc, which sends traffic logs to Tyk MDCB without a separate pump process. It has no aggregation support and runs inside the Gateway process itself. The Hybrid Pump is the current recommended approach. If you adopt the Hybrid Pump, set analytics_config.type to an empty string on your Data Plane Gateways to disable the legacy mechanism, otherwise both compete to send the same traffic logs to Tyk MDCB.

​

Connecting the Hybrid Pump to Tyk MDCB

To connect to Tyk MDCB, on the control plane, the Hybrid Pump needs to know where to find it (connection_string) and a secret to authenticate with (api_key).

api_key is the API key of a Tyk Dashboard user, obtained by registering a user scoped to the same Organisation as your data plane. See Tyk MDCB for that setup.

Set use_ssl: true to encrypt this connection over TLS. The Hybrid Pump is the TLS client and Tyk MDCB the server; there’s no client certificate involved, so this only encrypts the connection, it doesn’t identify the Pump to MDCB (api_key does that). If Tyk MDCB’s certificate isn’t trusted by your system’s CA pool, for example because it’s self-signed, set ssl_insecure_skip_verify: true rather than skip TLS entirely.

​

Hybrid Pump Meta

The Hybrid Pump is declared and configured like any other pump, as described in the Tyk Pump configuration guide, with both common and pump-specific settings. The specific settings live in meta:

{
  "pumps": {
    "hybrid": {
      "type": "hybrid",
      "meta": {
        "connection_string": "",       // required
        "api_key": "",                 // required
        "use_ssl": false,
        "ssl_insecure_skip_verify": false,
        "rpc_key": "",                 // unused
        "call_timeout": 10,
        "rpc_pool_size": 5,
        "aggregated": false,
        "track_all_paths": false,
        "store_analytics_per_minute": false,
        "enable_mcp_aggregation": false,
        "ignore_tag_prefix_list": []
      },
      ...
    }
  }
}

Field	Default	Description
connection_string	-	Tyk MDCB’s address, as host:port, for example mdcb.example.com:9091. Required
api_key	-	See Connecting the Hybrid Pump to Tyk MDCB above. Required
use_ssl	false	Connect to Tyk MDCB over TLS.
ssl_insecure_skip_verify	false	Skips TLS certificate verification when use_ssl is true.
rpc_key	-	Unused.
call_timeout	10	RPC call timeout, in seconds.
rpc_pool_size	5	RPC connection pool size, see Tuning the RPC Connection Pool below.
aggregated	false	See Traffic Logs or Aggregated Analytics below.
track_all_paths	false	See Traffic Logs or Aggregated Analytics below.
store_analytics_per_minute	false	See Traffic Logs or Aggregated Analytics below.
enable_mcp_aggregation	false	See Traffic Logs or Aggregated Analytics below.
ignore_tag_prefix_list	(none)	Prefixes of custom aggregation tags to exclude from aggregation, when aggregated is true.

​

Tuning the RPC Connection Pool

rpc_pool_size controls how many concurrent RPC connections the Hybrid Pump opens to Tyk MDCB. Each connection can carry data independently, so a larger pool lets the pump push more data to Tyk MDCB in parallel.

Consider increasing this value if:

• You’re running high API request volumes and the pump can’t keep up with sending data to Tyk MDCB.
• You’re sending (non-aggregated) traffic logs, which produce significantly more records than aggregated mode.

Each connection has a real cost on both ends: the Hybrid Pump and Tyk MDCB each allocate a 64KB send buffer and a 64KB receive buffer per connection. This cost accumulates across every data plane connected to Tyk MDCB, not just your own. From Tyk MDCB 2.13.0, the control plane can cap the connections it accepts, with server_options.max_connections.

Raising rpc_pool_size also has diminishing returns past a point: Tyk MDCB only processes up to 8,192 RPC calls concurrently by default, a limit shared across every connection from every data plane. Once that’s saturated, more connections just queue for the same shared budget rather than increasing overall throughput.

There’s usually no benefit to raising rpc_pool_size beyond your actual concurrency needs.

​

Traffic Logs or Aggregated Analytics

The Hybrid Pump can send every traffic log to Tyk MDCB, or it can create aggregated analytics.

The aggregated field controls this behavior:

• aggregated: false (default): the Hybrid Pump sends every traffic log to Tyk MDCB individually. This is the appropriate mode to use if you need to see the traffic in Tyk Dashboard’s Log Browser.
• aggregated: true: the Hybrid Pump summarizes traffic logs, before sending it to the Control Plane. This reduces the bandwidth requirement with less data crossing the (often expensive, sometimes cross-region) link to Tyk MDCB. The side-effect is that the individual traffic logs are not available to view in the Log Browser.

The tyk-data-plane Helm chart sets aggregated: true by default, to minimize traffic out of the box.

The following settings only take effect when aggregated: true; they have no effect on individual traffic logs:

• track_all_paths: aggregate all endpoints, not just tracked ones.
• store_analytics_per_minute: aggregate per minute rather than per hour.
• enable_mcp_aggregation: see MCP Proxy Traffic below.

​

How Tyk MDCB Handles The Data

Tyk MDCB receives either traffic logs or aggregated analytics from each Hybrid Pump, and writes it into the Control Plane’s persistent database that Tyk Dashboard reads from.

Aggregated analytics (generated if the Hybrid Pump is configured with aggregated: true) are written directly to the persistent database, for Tyk Dashboard’s Traffic Analytics graphs. This only happens when forward_analytics_to_pump and dont_store_aggregate are both false. Otherwise, Tyk MDCB discards them.

Traffic logs (aggregated: false) can be handled in one of two ways, controlled by Tyk MDCB’s forward_analytics_to_pump setting:

forward_analytics_to_pump	Behavior
false (default)	Tyk MDCB’s built-in writer processes the data.
true	Tyk MDCB stores the traffic logs in the Control Plane Redis instead, for a Control Plane Pump to process.

If you need to export the data from the Control Plane to a third-party sink such as Splunk or Datadog, you must first store it in the Control Plane Redis by setting forward_analytics_to_pump: true.

Tyk MDCB discards aggregated analytics when forward_analytics_to_pump is true. It doesn’t write them to the persistent database, nor does it pass them to the Control Plane Redis. If the Hybrid Pump is configured with aggregated: true, set forward_analytics_to_pump: false, or the Traffic Analytics graphs stay empty.

​

Tyk MDCB’s Built-In Writer

Tyk MDCB has much of the same capability as the dedicated Mongo/SQL pumps described in Control Plane Pumps, but not all of it. When forward_analytics_to_pump is false, this built-in writer will process the traffic logs received from the data planes.

This facility:

• Writes traffic logs directly to the Logs category of the persistent database, for the Log Browser
• In parallel, computes and writes aggregated analytics from that same data into Aggregate Analytics, for the Traffic Analytics graphs: the same computation the Mongo/SQL Aggregate Pumps perform

This is configured in Tyk MDCB’s own config file, tyk_sink.conf, not in pump.conf:

{
  "forward_analytics_to_pump": false,
  "analytics": {
    "type": "mongo",
    ...
  },
  "dont_store_selective": false,
  "dont_store_aggregate": false,
  "track_all_paths": false,
  "store_analytics_per_minute": false,
  "ignore_tag_prefix_list": []
}

The analytics object’s connection fields exactly mirror Common Mongo Meta or Common SQL Meta, depending on analytics.type; see those for the full field list rather than a third copy of it here.

Field	Default	Description
forward_analytics_to_pump	false	See How Tyk MDCB Handles The Data above.
analytics.type	mongo	Storage backend: mongo or postgres.
dont_store_selective	false	If true, skips writing per-Organisation storage, which otherwise mirrors the Per-Organisation Mongo Pump.
dont_store_aggregate	false	If true, stores no aggregated analytics. It doesn’t compute them from traffic logs, and it discards any aggregated analytics sent by a Hybrid Pump configured with aggregated: true.
track_all_paths	false	Aggregate all endpoints, not just tracked ones.
store_analytics_per_minute	false	Aggregate per minute rather than per hour.
ignore_tag_prefix_list	(none)	Prefixes of custom aggregation tags to exclude from aggregation.

Limitations:

• No filtering: there’s no equivalent to a Tyk Pump’s filters setting (org_ids, api_ids, response_codes, and their skip_* counterparts). Every request that reaches Tyk MDCB is stored; you can’t exclude specific APIs, Organisations, or response codes.
• No MySQL support: analytics.type only recognizes mongo and postgres; any other value, including mysql, is accepted but silently falls back to mongo rather than failing.
• GraphQL analytics on SQL only: with MongoDB, GraphQL requests are stored as ordinary traffic logs and aggregated analytics only. See GraphQL Traffic below.

If you need MySQL, filtering, or a third-party sink, use a Control Plane Pump instead: set forward_analytics_to_pump: true and configure the Control Plane Pump as any other Control Plane Pump.

​

Choosing a Configuration

This table covers REST traffic; see GraphQL Traffic and MCP Proxy Traffic below for how those differ.

Goal	Hybrid Pump aggregated	Tyk MDCB forward_analytics_to_pump
Traffic Analytics graphs only, minimize WAN traffic	true	false
Traffic Analytics graphs and Log Browser	false	false
Traffic Analytics graphs, Log Browser, and third-party sinks	false	true, with a Control Plane Pump configured to write to both the Control Plane persistent database and your third-party sink
Third-party sink only, minimal Tyk Dashboard dependency	Run a separate OpenTelemetry integration on the Gateway instead	n/a

​

GraphQL Traffic

Tyk Gateway records GraphQL-specific details with each GraphQL request. When the Hybrid Pump’s aggregated is false, it passes these details to Tyk MDCB unchanged.

With SQL and forward_analytics_to_pump: false, Tyk MDCB’s built-in writer stores GraphQL traffic logs and aggregated analytics in dedicated GraphQL tables. It does this the same way as the sql-graph and sql-graph-aggregate pumps in a combined deployment, and it populates the Activity by Graph screen.

GraphQL traffic doesn’t populate Activity by Graph when:

• Tyk MDCB uses MongoDB. GraphQL requests are stored as ordinary traffic logs and aggregated analytics only.
• The Hybrid Pump is configured with aggregated: true. The Hybrid Pump doesn’t create GraphQL aggregated analytics.

In both cases, GraphQL requests are still included in the general aggregated analytics, and in Log Browser when aggregated is false.

​

MCP Proxy Traffic

MCP proxy traffic differs from REST traffic in two ways. Tyk Dashboard’s Log Browser never reads MCP traffic logs, in any topology. And the Hybrid Pump only aggregates MCP traffic when configured to do so.

When the Hybrid Pump’s aggregated is false, it sends MCP traffic logs to Tyk MDCB along with other traffic logs. With forward_analytics_to_pump: false, Tyk MDCB’s built-in writer stores them in the Control Plane’s persistent database for your own downstream querying. It also computes MCP aggregated analytics from them, for Activity by MCP.

With forward_analytics_to_pump: true, add an MCP aggregate pump type (mongo-mcp-aggregate or sql-mcp-aggregate) to the Control Plane Pump to populate Activity by MCP.

When aggregated is true, set enable_mcp_aggregation: true on the Hybrid Pump to populate Activity by MCP. The Hybrid Pump then aggregates MCP traffic on the data plane before sending it, and the individual MCP traffic logs are lost. REST traffic has the same trade-off.

If aggregated is true on the Hybrid Pump and enable_mcp_aggregation is false (the default), the Hybrid Pump discards MCP analytics. It sends no MCP aggregated analytics and no MCP traffic logs, because aggregated: true stops all traffic logs. REST traffic is still aggregated in this mode.