AI-Driven DDoS Protection System Using Temporal Workflow Orchestration

salesforce · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.0 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Real-time DDoS protection for multi-tenant cloud infrastructure

Salesforce needed machine-speed DDoS detection and mitigation across shared global infrastructure where attacks against one tenant could affect others.

Constraints:

high-stakes false-positive risk
distributed cloud regions
subsecond response expectations
large traffic-analysis payloads

Architecture

Salesforce DREAM is a distributed DDoS response platform layered on Hyperforce and Temporal-as-a-service. A DREAM API response/mitigation layer detects suspicious traffic, runs AI inference over L7 and L3/L4 plus historical features, and passes quantitative outputs into an AI decision layer that produces mitigation strategies and actor classifications. A DREAM Temporal integration layer schedules workflows, separates lightweight deterministic workflow workers from heavier activity workers, calls external services such as PagerDuty/Slack, and programs edge cloud policies for mitigation while preserving human validation for false-positive risk.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  ddos-signal-detector[DDoS signal detector] --> dream-temporal-integration[DREAM Temporal integration]
  dream-api-response-and-mitigation[DREAM API response and mitigation] --> ddos-signal-detector
  dream-api-response-and-mitigation --> ai-inference-layer[AI inference layer]
  ai-inference-layer --> ai-decision-layer[AI decision layer]
  dream-temporal-integration --> temporal-cluster[Temporal cluster]
  temporal-cluster --> workflow-workers[Workflow workers]
  workflow-workers --> activity-workers[Activity workers]
  activity-workers --> ai-inference-layer
  activity-workers --> notification-services[Notification services]
  activity-workers --> edge-mitigation-policies[Edge mitigation policies]
  ai-decision-layer --> edge-mitigation-policies[Edge mitigation policies]
  ai-decision-layer --> human-review-loop[Human review loop]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`DREAM API response and mitigation`	Business-logic layer containing DDoS detection, AI-driven inference, and DDoS mitigation.	`DDoS signal detector`, `AI inference layer`, `AI decision layer`, `DREAM Temporal integration`
`DDoS signal detector`	Detects suspicious network-traffic activity and initiates the Temporal workflow path.	`DREAM API response and mitigation`, `DREAM Temporal integration`
`DREAM Temporal integration`	Adapter layer that interacts with Temporal clusters, the external world, and the DREAM response/mitigation logic.	`DDoS signal detector`, `Temporal cluster`, `Workflow workers`, `Activity workers`, `Notification services`, `AI inference layer`, `Edge mitigation policies`
`Temporal cluster`	Salesforce Temporal-as-a-service clusters provided on Hyperforce to schedule workflows and activities.	`DREAM Temporal integration`, `Workflow workers`, `Activity workers`
`Workflow workers`	Lightweight deterministic control-plane workers that pick up workflows and schedule activities.	`Temporal cluster`, `Activity workers`
`Activity workers`	Heavier workers with CPU/process-pool capacity for AI inference calls, notifications, external service calls, and mitigation actions.	`Temporal cluster`, `Workflow workers`, `AI inference layer`, `Notification services`, `Edge mitigation policies`
`AI inference layer`	Analyzes L7 traffic plus L3/L4 and historical features to emit quantitative likelihood signals.	`DREAM API response and mitigation`, `Activity workers`, `AI decision layer`
`AI decision layer`	Transforms quantitative inference signals into threat assessment, good/bad/unknown actors, and a mitigation strategy.	`DREAM API response and mitigation`, `AI inference layer`, `Edge mitigation policies`
`Notification services`	External communication channels such as PagerDuty and Slack used to notify teams during potential attacks.	`DREAM Temporal integration`, `Activity workers`
`Edge mitigation policies`	Cloud-edge infrastructure policies programmed to filter bad traffic and let good traffic through.	`DREAM Temporal integration`, `Activity workers`, `AI decision layer`
`Human review loop`	Human validation path for false-positive-sensitive resolution and final decision acceleration.	`AI decision layer`, `Edge mitigation policies`

Data flow

DREAM starts when the DDoS protection component detects suspicious network-traffic signals in Salesforce infrastructure. It calls the DREAM Temporal integration API, which schedules workflows in the Temporal cluster. Workflow workers pick up work, decide the deterministic execution flow, and schedule activities. Activity workers run the real work: invoke AI inference, send notifications, and execute mitigation. The inference layer scores L7 connection/header/body features and L3/L4 IP/history signals; the decision layer turns the scores into threat assessment, good/bad/unknown actors, and a mitigation strategy. Mitigation activities then program cloud edge infrastructure with policies, while human reviewers receive richer context for final validation where false positives would be costly.

4 supporting quotes

“When we detect those signals we make an API call to the dream temporal integration which in turn schedules the workflows within the temporal cluster.”transcript, stated

“Now our workflow workers start picking up the work from the temporal cluster and in turn determine the execution flow and push down and schedule new activities down to the temporal cluster again.”transcript, stated

“the activity workers pull the their activity tasks from the temporal as a service cluster and perform the the actual work.”transcript, stated

“So this quantitative data is pushed to the layer below which we call the AI decision layer.”transcript, stated

Why this architecture

DREAM chose Temporal because the platform requirements were distributed execution, fault tolerance, concurrency control, locks, and visibility across global Salesforce infrastructure. Building those primitives from scratch or stitching Kafka, Airflow, ZooKeeper, and related systems would have delayed business logic and added operational failure points. Temporal lets the team focus on DDoS defense logic while enforcing a workflow/activity split that makes code more maintainable and allows separate resource profiles for lightweight orchestration versus compute-heavy mitigation and AI work.

4 supporting quotes

“Temporal for us it was the ideal solution here because it provides all those requirements the strict requirements for us they were provided by temporal out of the box.”transcript, stated

“we can focus on the business logic we can focus on the defense logic of Salesforce from day one.”transcript, stated

“We use workflows to control the execution flows in a deterministic way and we use the activity to interact with external work”transcript, stated

“The reason are like uh fault tolerance and different requirements in terms of CPU memory”transcript, stated

Models used: AI inference models · machine learning decision layer

Scale

Salesforce described sophisticated DDoS attacks as increasing roughly 70-80x over two years, with machine-speed attacks requiring machine-speed defense.
“it is about 70 to 80 times increase in these sophisticated attacks not only in the volume but also the quality sophistication and complexity”transcript, stated
The mission targets subsecond detection, mitigation, and remediation rather than post-incident forensics.
“So we are building systems which are like subsecond detection, subsecond mitigation, subsecond remediation”transcript, stated
DREAM operates across Salesforce distributed cloud regions and must protect shared multi-tenant infrastructure where one attacked tenant can affect others.
“we operate on a distributed network on a distributed cloud infrastructure where we need to provide protection across the entire globe across the entire regions”transcript, stated
The Temporal migration reportedly improved first mitigation by 10x, analysis cycle by 15x, and end-to-end resolution by 3x.
“We saw 10x improvements from our previous system when we from our previous system to temporal when we moved to temporal”transcript, stated
Production context payloads hit a 2 MB parameter limit and replay timeouts around 5-10 seconds when workflow history bloated.
“every parame parameter on your uh path gets a 2 MB limit the wall.”transcript, stated

Alternatives considered (roads not taken)

Build all distributed orchestration requirements from scratch

Rejected because: It would take months to reimplement solved primitives before writing DDoS defense logic.

“We could have spent months reimplementing them reinventing the wheel but it would have taken months uh just to reimplement them without writing any single line of actual business code”transcript, stated

Stitch together Kafka, Airflow, ZooKeeper, and similar tools

Rejected because: Each tool would introduce its own failure point and operational burden.

“But stitching all the pieces together, you know, they all comes with different failure points and then each one of them would add some operational burden to the picture.”transcript, stated

One combined worker pool for workflows and activities

Rejected because: Workflow control is lightweight while activities can be CPU intensive, so they need different resources, queues, and fault domains.

“the decision here was to keep the workflow workers separate from the activity workers both in terms of the actual workers and also in terms of the cues”transcript, stated

Passing large analysis context through Temporal history

Rejected because: It bloated history, hit gRPC/protobuf limits, and caused replay timeouts; external storage and continue-as-new kept Temporal as coordinator rather than data warehouse.

“Temporal is awesome coordinator orchestrator but not a data warehouse.”transcript, stated

Fully autonomous mitigation without human validation

Rejected because: False-positive blocks are too risky, so resolution keeps humans in the loop with richer context and evidence.

“The human in loop is a very critical part of our game. Uh we will have to make sure we are not doing any false positive uh blocks or mitigations.”transcript, stated

Patterns

`durable-execution` (orchestration)

Temporal workflows control deterministic execution while activities perform external work such as LLM calls, notifications, and mitigation steps.

“We use workflows to control the execution flows in a deterministic way and we use the activity to interact with external work when we want to talk with to the LLMs when we want to um reach out external services”transcript, stated

`human-in-the-loop-gate` (safety)

Critical resolution still includes human validation so automated mitigations do not block legitimate customer traffic.

“the end to end resolution was again 3x improvement over there because our resolution also includes a human in loop. The human in loop is a very critical part of our game.”transcript, stated

Tradeoffs

How to separate workflow control from compute-heavy mitigation work.

Chose separate workflow and activity workers over one undifferentiated worker pool.

Rationale: Separate workers add deployment surface area but give fault isolation and resource profiles that match lightweight control flow versus CPU-heavy activities.

“the decision here was to keep the workflow workers separate from the activity workers both in terms of the actual workers and also in terms of the cues”transcript, stated

Core orchestration platform choice for DREAM.

Chose Temporal as the distributed workflow substrate over building primitives from scratch or stitching Kafka/Airflow/ZooKeeper-style tools.

Rationale: Temporal supplied the strict distributed-system requirements out of the box, reducing time spent on infrastructure primitives and operational integration burden.

“So the third option was to use temporal. Temporal for us it was the ideal solution here because it provides all those requirements”transcript, stated

How to keep Temporal workflow histories from becoming the data plane.

Chose S3/data offload plus continue-as-new when history approaches threshold over passing large analysis context through workflow/activity parameters indefinitely.

Rationale: Temporal should coordinate workflows, not carry number-crunching payloads; offload and continue-as-new avoided 2 MB walls and replay timeouts.

“S3 offload or any other uh data offload like you don't put your context make your history bloating up inside temporal”transcript, stated

How much mitigation authority to automate.

Chose autonomous mitigation workflows with a human review loop for resolution over fully automatic blocking decisions without human validation.

Rationale: The system needs machine-speed mitigation but false-positive blocks are dangerous, so human reviewers get richer context to decide faster.

“with temporal we were able to give richer context back to this uh human to get more feedback faster and to run uh to have more validations for them”transcript, stated

How to express parallel workflow waiting in Temporal code.

Chose Temporal workflow wait semantics with SDK context over plain Python asyncio gather/set patterns.

Rationale: Common async patterns can be nondeterministic and break Temporal replay guarantees.

“The problem with async IO is uh that it uses Python set which is unordered. Unordered becomes undeterministic.”transcript, stated

Gotchas (what bit them)

Temporal histories bloated when the workflow carried too much analysis context.

Root cause: The team was using Temporal like a data warehouse for number-crunching payloads rather than keeping it focused on orchestration.

Resolution: Offload large context to S3 and use continue-as-new to prune workflow history near the 2 MB threshold.

“One was the timeout trap. The other one was the 2 MB wall. We will spend a little time to discuss uh what was these two things. Timeout trap. Uh so the lesson is don't use temporal as a data warehouse.”transcript, stated

Evaluation

Salesforce compared mitigation, analysis, and end-to-end resolution performance against the previous DDoS protection system.

Metrics: 10x time-to-mitigation improvement · 15x faster analysis cycle · 3x end-to-end resolution improvement

“We saw 10x improvements from our previous system when we from our previous system to temporal when we moved to temporal which also in other words means we are protecting our customers 10x faster.”transcript, stated

Outcomes

DREAM protects customers faster by combining AI traffic classification with Temporal-orchestrated mitigation workflows.
The system improved analysis and resolution while preserving human review for risky decisions.

Conference transcript from Salesforce network-security engineers; metrics are self-reported production improvements.

“Again, lot of number crunching 15x faster than our previous system. This gives us more headroom to put even more better analysis and make our mitigation strategies better.”transcript, stated