How to Architect Obsidian Pulse

Question

Absolutely—here’s a comprehensive summary of the Obsidian Pulse architecture, with full context to share with Azure Support for feedback, validation, and potential optimizations.

---

Summary: Obsidian Pulse Architecture for Banque de Diéu

System Overview

Obsidian Pulse is the autonomous orchestration heartbeat of the Banque de Diéu digital finance ecosystem. It is a continuously running service that acts as the platform’s real-time nervous system, executing high-frequency tasks such as:

Payment event processing

Sending and dispatching user notifications

Self-healing operations (e.g., anomaly detection, response)

Scheduled tasks

Triggering data sync or reconciliation logic

The name Obsidian Pulse reflects its nature: a dark, resilient, always-beating core.

---

Key Functional Concept

At its simplest, the Pulse runs in an infinite loop or background service, consuming messages from a central Azure Service Bus topic. These messages are typically raised by the core Payments API or other components of the platform.

Each pulse (iteration) can:

1. Dequeue messages from the payment-processed topic.
2. Log and interpret the data.
3. Trigger secondary logic (e.g., notifications, audit logs, machine learning risk scans).
4. Re-enter sleep state or proceed to the next message.

---

Current & Proposed Architecture

1. Components

Payments API (Azure App Service or Container App)

Sends messages to Azure Service Bus when a payment is completed.

Does not contain any notification logic—it simply emits events.

Azure Service Bus

Topic: payment-processed

Acts as a decoupling point for downstream processing (i.e., Obsidian Pulse).

Obsidian Pulse

.NET Core Worker Service (planned for MAUI Console App or hosted agent)

Pulls from the Service Bus

Triggers notifications, logs, adaptive behavior.

---

2. Hosting Options for Obsidian Pulse

---

3. Configuration Options for Pulse Discovery

Rather than hardcoding Service Bus names, use one of:

Environment Variables: SERVICEBUS_TOPIC_NAME, SERVICEBUS_CONNECTIONSTRING

Azure App Configuration or Azure Key Vault: Central secure storage

Central Registry / Config Microservice (future-proof): Dynamic resolution

---

4. Notifications Architecture

Use Azure Service Bus topics and subscriptions for distributing notifications to:

Mobile push via Azure Notification Hub

Email alerts via SendGrid or Logic Apps

WebSockets/SignalR for real-time frontend updates

---

5. Developer Notes

Worker service is currently being developed in .NET 9 with optional Hangfire integration for delayed/scheduled tasks.

Obsidian Pulse will eventually support multi-tasking, prioritization, and dynamic learning (self-healing AI).

---

Questions for Azure Support / Recommendations Requested

1. What is Azure's recommended hosting approach for a continuously running .NET Core background service like this?

WebJob, Azure Container App, VM, or another?

2. How should we best ensure high availability and auto-restart behavior for the Pulse if a crash occurs?
3. Are there any best practices to log, trace, and monitor each heartbeat of the Pulse using Application Insights or another service?
4. Should Service Bus be split into multiple topics for different domains (payments, audit, notification)? Or use filters on a single topic?
5. Any other observability/telemetry tools Azure recommends to make each Pulse traceable and measurable?

---

Next Steps

Banque de Diéu is in MVP stage. This architectural choice is being made early to lay a foundation for:

Scalable, observable, reactive finance

Digital currency orchestration (CBDC)

Global compliance and autonomy

We seek Azure’s insight on how best to host and evolve the Obsidian Pulse.