Last modified: Jun 27, 2024



Public API

The following API controllers are defined:

Private API

The API controllers listed below are exclusively for use within the Notification solution:


Events data is persisted in a PostgreSQL database.


Each table in the events schema is described in the table below, followed by a diagram showing the relation between the tables.

eventsContains each cloud event and the registered time
subscriptionHolds metadata for each event subscription

Diagram of Events Database
Diagram of Events Database


A number of indexes have been introduces to increased performance of the frequently used queries.


Azure Storage Queues

Azure Storage Queues have been set up to enable the .NET application and Azure Functions to send data for processing by a different service.

Logic for enqueueing elements is handled by EventsQueueClient and called from all relevant services.

The queues we operate with are

  • events-registration
  • events-inbound
  • events-outbound
  • subscription-validation

Azure Functions

Multiple Azure Functions have been set up to decouple the processing and pushing of events as well as subscription validation. All functions run based on Storage Queue triggers. An important principle for the functions is that each function should only have a single dependency to a logical action e.g. save to database, push to recipient etc. This way, if the action fails a retry can be done without any unexpected side effects.

  • EventsRegistration : Pushes events to internal API endpoint that persists cloud event to database and on success pushes to internal API endpoint for inbound processing.
  • EventsInbound : Pushes event to internal API endpoint that finds subscriptions with filters matching the cloud event.
  • EventsOutbound POST cloud event to webhook endpoint associated with a subscription.
  • SubscriptionValidation POST validation cloud event to user-defined webhook endpoint to check that it is ready to receive data. If so, a request is sent to internal API endpoint that updated the status in the database.
NameTrigger queueRetry mechanism


The microservice takes use of a range of external and Altinn services as well as .NET libraries to support the provided functionality. Find descriptions of key dependencies below.

External Services

Azure Database for PostgreSQLHosts the databaseDocumentation
Azure API ManagementManages access to public APIDocumentation
Azure FunctionsHosts the server less functionsDocumentation
Azure Key VaultSafeguards secrets used by the microserviceDocumentation
Azure Kubernetes Services (AKS)Hosts the microservice and cron jobsDocumentation
Azure MonitorTelemetry from the application is sent to Application InsightsDocumentation
Azure StorageHosts the queues and persists data in queuesDocumentation

Altinn Services

Altinn AuthorizationAuthorizes access to the APIRepository
Altinn RegisterProvides lookup of alternative subjects person and orgRepository

.NET Libraries

The Events microservice and functions take use of a range of libraries to support the provided functionality.

Azure.Storage.QueuesUsed to send data to the storage queuesRepository, Documentation
CloudNative.CloudEvents.AspNetCoreUsed for encoding and decoding cloud eventsRepository, Documentation
AccessTokenUsed to validate tokens in requestsRepository, Documentation
JWTCookieAuthenticationUsed to validate Altinn token (JWT)Repository, Documentation
NpgsqlUsed to access the database serverRepository, Documentation
YuniqlDB migrationRepository, Documentation

A full list of NuGet dependencies is available on GitHub.


Quality gates implemented for a project require an 80 % code coverage for the unit and integration tests combined. xUnit is the framework used and the Moq library supports mocking parts of the solution.

Unit tests

The unit test projects are is available on GitHub.

Integration tests

No integration tests using external components haeve ben implemented for this solution. Look to unit test project for all tests related to Events.

Automated tests

The automated test project is available on GitHub

The automated tests for this micro service are implemented through Grafana’s k6. The tool is specialized for load tests, but we do use it for automated API tests as well. The test set is used for both use case and regression tests.

Use case tests

All use case workflows are available on GitHub

Use case tests are run every 15 minutes through GitHub Actions. The tests run during the use case tests are defined in the k6 test project. The aim of the tests is to run through central functionality of the solution to ensure that it is running and available to our end users.

Regression tests

Regression tests are hosted in Azure DevOps pipelines and triggered at the end of a release pipeline.



The microservice runs in a Docker container hosted in AKS, and it is deployed as a Kubernetes deployment with autoscaling capabilities

The events application runs on port 5090.

See DockerFile for details.

Azure Functions

The Azure functions are hosted in a function app only containing event related functions.

Azure Storage

The Storage Queues are hosted in a geo-zone-redundant, general purpose v2 storage account.


The database is hosted on a PostgreSQL flexible server in Azure.

Build & deploy


Azure Functions

-Build of the Azure Function zip file is done in an Azure DevOps Pipeline


  • Migration scripts are copied into the Docker image of the web API when this is build
  • Execution of the scripts is on startup of the application and enabled by YUNIQL

Run on local machine

Instructions on how to set up the service on local machine for development or testing is covered by the README in the repository.