Skip to DART content

Architecture and operations

Understand how DART runs. See where the application connects to the database and outside services.

The application and database

The screens people use are one part of the system that keeps their work consistent. DART uses Next.js and React for its web application. Server-side JavaScript applies the rules. PostgreSQL stores the operational records and their history.

The main work areas have separate services. Each service checks its own commands and permissions. The database also protects saved versions and events from being overwritten.

Application and service boundariesDomain services enforce the rules. The deployment configures identity, database, workers, files, and external providers.Identity providerDART servicesPostgreSQL historyPrivate providers
Domain services enforce the rules. The deployment configures identity, database, workers, files, and external providers.

Saved background jobs

Some tasks take longer than the user should need to wait on a page. Background jobs handle work that can finish after a request returns. A report build is one example. Notification delivery and source capture also use saved jobs.

A worker checks the saved request before running it. It checks current access where the workflow requires it. Held jobs remain available for review and retry.

Connected services

The application relies on other services for work such as sign-in and message delivery. The deployment connects the application to approved services. These include identity and file storage. Communications and translation use their configured providers.

GovCloud adapters are available for the relevant service paths. Each connection needs the right account and network access. Deployment tests verify the chosen setup.

BoundaryDeployment responsibility
IdentityConnect the approved sign-in provider and map each user.
DatabaseSet the environment and database permissions. Configure backups.
FilesSet up private storage and scanning. Test file recovery.
WorkersSchedule jobs and monitor failures.
CommunicationsConnect the providers and test delivery and calls.
MonitoringSend system events to the operations team.

Test performance and recovery

An incident can place more demand on the system than an ordinary working day. Performance records show request times and failures. Staff can review them when planning a change. Test results remain attached to the change record.

Load tests measure the chosen deployment. They should cover incident surges and report workloads. Recovery tests confirm that backups can be restored.

The test results establish operating limits. The presence of retry code alone does not prove surge capacity.

Define the production system

A production system needs clear responsibility for both the software and the services around it. The production plan names who operates each service. It states who controls identities and keys. It also defines how software changes are approved.

An agency authorizes a specific system in a specific environment. The application code is one part of that system. The assessment must also cover its hosting and operations.