You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/architecture/design/notifications.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -72,7 +72,7 @@ Notifications that have no matching rules are discarded immediately.
72
72
73
73
The outbox relay is a background process that continuously polls the `NOTIFICATION_OUTBOX` table,
74
74
routes notifications to matching rules, and schedules publishing workflows.
75
-
The polling interval is configurable via [`notification.outbox-relay.poll-interval-ms`](../../reference/configuration/api-server.md#notificationoutbox-relaypoll-interval-ms),
75
+
The polling interval is configurable via [`dt.notification.outbox-relay.poll-interval-ms`](../../reference/configuration/api-server.md#dtnotificationoutbox-relaypoll-interval-ms),
76
76
and defaults to 1 second.
77
77
78
78
```mermaid
@@ -103,7 +103,7 @@ sequenceDiagram
103
103
Transaction-level [advisory locks] prevent concurrent relay cycles across multiple API server instances.
104
104
This ensures notifications are relayed in approximately the order they were emitted.
105
105
The lack of concurrency is offset by batch processing. The batch size is configurable
106
-
via [`notification.outbox-relay.batch-size`](../../reference/configuration/api-server.md#notificationoutbox-relaybatch-size)
106
+
via [`dt.notification.outbox-relay.batch-size`](../../reference/configuration/api-server.md#dtnotificationoutbox-relaybatch-size)
Copy file name to clipboardExpand all lines: docs/index.md
+13-17Lines changed: 13 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,21 +5,18 @@
5
5
6
6
## Introduction
7
7
8
-
Project *Hyades*, named after [the star cluster closest to earth], is an *incubating* project for decoupling
9
-
responsibilities from [Dependency-Track]'s monolithic API server into separate, scalable™ services.
8
+
Project *Hyades*, named after [the star cluster closest to earth], is the next generation of Dependency-Track,
9
+
rearchitected for scale, resilience, and ease of operation.
10
10
11
11
The main objectives of Hyades are:
12
12
13
-
* Enable Dependency-Track to handle portfolios spanning *hundreds of thousands of projects*
14
-
* Improve *resilience* of Dependency-Track, providing *more confidence* when relying on it in critical workflows
15
-
* Improve deployment and configuration management experience for containerized / cloud native tech stacks
13
+
* Enable Dependency-Track to handle portfolios spanning *hundreds of thousands of projects*.
14
+
* Improve *resilience* of Dependency-Track, providing *more confidence* when relying on it in critical workflows.
15
+
* Improve deployment and configuration management experience for containerized / cloud native tech stacks.
16
16
17
-
Other than separating responsibilities, the API server has been modified to allow for high availability
18
-
(active-active) deployments. Various "hot paths", like processing of uploaded BOMs, have been optimized
19
-
in the existing code. Further optimization is an ongoing effort.
20
-
21
-
Hyades already is a *superset* of Dependency-Track, as changes up to Dependency-Track v4.11.4 were ported,
22
-
and features made possible by the new architecture have been implemented on top.
17
+
To achieve this, the platform has undergone significant architectural improvements, including [durable execution]
18
+
for reliable background processing, a PostgreSQL-optimized persistence layer, a [new CEL-based policy engine],
19
+
and a modernized [configuration system].
23
20
24
21
!!! warning
25
22
Hyades is not yet fully production ready, please refer to the
@@ -34,7 +31,7 @@ and features made possible by the new architecture have been implemented on top.
34
31
??? abstract "tl;dr"
35
32
The architecture of Dependency-Track v4 prevents it from scaling past a certain workload.
36
33
37
-
Dependency-Track, for the most part, is an event-based system. As a platform for ingesting data (in the form of BOMs),
34
+
Dependency-Track v4, for the most part, is an event-based system. As a platform for ingesting data (in the form of BOMs),
38
35
listening for and itself emitting signals on it, an event-based architecture makes sense conceptually. The majority of
39
36
operations Dependency-Track performs happen asynchronously, without client interaction.
40
37
@@ -100,8 +97,6 @@ While this architecture works great for small to medium workloads, it presents v
100
97
would be an even bigger problem if the work was shared across multiple application instances, and would require
101
98
distributed locking as a countermeasure, which is [inherently hard to get right](https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html).
102
99
103
-
In order to scale Dependency-Track beyond its current capabilities, a distributed messaging service is required.
104
-
105
100
### Related Issues
106
101
107
102
On multiple occasions in the past, the Dependency-Track community raised questions about high availability (HA)
@@ -112,9 +107,10 @@ deployments, and / or how to better scale the platform:
0 commit comments