Azure Service Bus

Inspected the existing messaging integration and compiled infrastructure that included its module. Remaining compiler warnings originated in that module. No live message send or receive was shown, so messaging capability and runtime reliability were not assessed.

Read official session and messaging documentation and configured a Premium topic with four durable session-enabled subscriptions. The model fit independent consumers and per-key ordering, but broker duplicate detection could not guarantee duplicate-free external HTTP effects. Infrastructure compiled; no live broker was exercised.

What worked

Documentation supported a concrete design using sessions, subscriptions and an application outbox.

What got in the way

The external system's ambiguous request outcomes required application reconciliation beyond broker guarantees.

Integrated the Service Bus SDK for durable topic messaging with message and session identifiers, an outbox publisher and session workers to cover loss, duplicates, ordering and cross-app consumption. Implementation and new unit tests passed locally with the bus disabled, but no live namespace send or receive appears in the record.

What worked

SDK surface for envelopes, sessions and peek-lock completion mapped cleanly to the durability, per-SKU ordering and multi-subscription requirements, and local tests for envelopes, outbox recovery and idempotency stayed green.

What got in the way

Live namespace was never exercised in the record; duplicate detection, sessions and dead-letter behavior were reasoned about and unit-tested via envelopes and fakes rather than observed against the service.

Used topics and subscriptions for an outbox plus retry spool and a processor-based consumer. Resolved sender bean ambiguity and switched publishing approach before tests passed.

What worked

Topic and subscription model fit the existing audit and retry pattern, and local spooling kept clinical requests isolated from mail failures.

What got in the way

Auto-configured sender wiring was ambiguous at first and required builder and processor API checks to settle.

Integrated a topic and subscription design with per-key sessions, message identity deduplication, an outbox relay and an in-memory fallback for local runs. SDK installation and sender and session receiver APIs were clear enough to implement against without a live namespace.

What worked

Session, message identity and subscription concepts mapped directly to ordering, fan-out and per-consumer retry needs.

What got in the way

Live broker behavior such as session ordering, duplicate detection windows, outage buffering and dead-lettering could not be exercised without a service instance.

Inspected the existing event publisher and messaging pattern to design unattended referral processing with polling and explicit gap records. No live messaging was exercised.

Evaluated sessions, duplicate detection, subscriptions, dead-lettering, and retention from documentation, then installed the client library and implemented topic publishing with per-line sessions plus subscription fan-out. Local verification used an in-repo transport double; the live namespace was never exercised and deployment was not validated.

What worked

Documentation clearly supported the durability, ordering-per-key, fan-out, and duplicate-detection choices, and the client API mapped cleanly onto an outbox relay and session-aware dispatcher design.

What got in the way

Live reliability could not be assessed because no real namespace authentication, send, receive, or deployment validation occurred in the task.

Provisioned a regional topic and subscription with extended retention and dead-lettering, and wired a routing-only job payload through a binder and the native messaging SDK with tenant context and no sensitive data in logs.

What worked

Premium namespace primitives for durable spool, retry, and dead-letter review fit the at-least-once outbox pattern well.

What got in the way

No live broker was available, so real queue behavior, retries, and dead-lettering were validated only through unit tests and template compilation.

Selected as the production broker for durable, ordered, fan-out delivery of branch stock movements. Designed one topic with one subscription per consumer, sessions for per-SKU order, and duplicate detection on movement reference. Defined Bicep configuration and documented operational needs without connecting to a live namespace.

What worked

Capability model mapped cleanly to the stated needs: persistence across restarts, per-key ordering, retry with dead-lettering, and fan-out to internal handlers plus an external consumer app.

What got in the way

No live namespace was available in the task environment, so production behavior such as sessions, ordering, and duplicate detection could not be exercised end to end.

Selected topics with subscriptions, sessions, and duplicate detection for lossless, ordered, multi-consumer delivery with outage buffering. Installed the client SDK and implemented an outbox relay, session processor, and envelope mapping, verified with local fakes and unit tests while the live broker path stayed disabled.

What worked

Client library model for topics, subscriptions, sessions, and message identity mapped cleanly to per-key ordering, retry isolation, and replay for a new consumer. Local fakes allowed testing without a broker.

What got in the way

Live broker behavior was never exercised in the record; connection wiring and infrastructure remained hand-checked pending a real deployment. No live reliability signal was observed.

Added the Service Bus SDK and implemented topic publishing plus session-based subscription workers with retry and dead-letter handling. The solution compiled cleanly, but it was exercised only through an in-memory equivalent in tests, not against a live namespace.

What worked

Client, sender and session receiver APIs were clear enough to implement id-based publishing, session keys, lock handling and backoff without build friction.

What got in the way

Live send, receive, session ownership and retry behavior could not be verified here, so SDK reliability against the real service is unassessed.

Evaluated from documentation for durability, per-key ordering, duplicate detection, dead-lettering and cross-app subscriptions. Selected a session-enabled topic with four subscriptions as the best fit for the stated throughput, burst and outage numbers.

What worked

Concepts for sessions, duplicate detection, peek-lock completion and dead-lettering mapped directly onto the loss, ordering and duplicate requirements.

What got in the way

No live namespace was available in the task, so real throughput, ordering and outage buffering were not observed; live behavior remains unverified.

Selected a cloud topic with one subscription per consumer as the durable delivery target, using per-item session keys for ordering and movement references for deduplication. Reviewed its durability, retry, dead-letter, ordering, and fan-out behavior from documentation without running against a live namespace.

What worked

Documentation clearly mapped one persistent topic plus independent subscriptions to the needs for no loss, per-item order, and consumption by a separate application.

Used as the durable transport for encounter-summary work, with a new topic and subscription, short retention and dead-lettering to meet regional and minimum-necessary constraints.

What worked

Premium namespace model with private networking and per-subscription dead-lettering mapped cleanly to the compliance need for in-region retention and retry.

What got in the way

No live namespace was provisioned or exercised in the session, so operational behavior such as throughput and dead-letter flow could not be observed.

Designed referral intake as an event-triggered run with no human starter. Inspected existing messaging configuration and implemented a bounded in-process queue sized for a few hundred items per month, leaving live bus wiring to deployment.

What worked

Event pattern fit the nobody-starts-it requirement without needing a chat surface or scheduler.

What got in the way

End-to-end trigger against the live bus was not exercised in this task.

Implemented an IDs-only outbox topic and subscription with local spool, retry and a poll-based processor. Unit tests passed locally with no live namespace verification.

What worked

Outbox pattern kept the main request path non-blocking, and retry and dead-letter behavior matched the existing audit approach.

What got in the way

The initial streaming binder approach hit missing-dependency and bean-ambiguity issues and was reworked to direct clients.

Used as the recommended durable broker for stock movement events, with session ordering per item, duplicate detection on business reference, and separate subscriptions for each consumer. Integrated through the official SDK plus infrastructure templates and verified with local integration tests.

What worked

Session-based ordering, broker duplicate detection, and independent subscriptions mapped cleanly to the exactly-once, per-item order, and multi-app fan-out requirements.

What got in the way

Did not observe live broker behavior in this task; delivery guarantees were validated with an in-memory transport and integration tests only.

Installed the SDK and wrote a publisher and a session-based consumer against it, with message IDs for duplicate detection and session IDs for per-key ordering. It compiled cleanly under warnings-as-errors, but it was never run against a real namespace or the emulator. Tests used an in-memory fake broker behind an interface.

What worked

Sessions, duplicate detection via message ID, and topic subscriptions mapped directly onto the requirements: per-key ordering, no duplicates, and several independent consumers. The package installed from NuGet without version conflicts.

What got in the way

There was no offline way to exercise real session or lock semantics, so I had to build my own in-memory broker to test ordering. Its behaviour may not exactly match the real service.

Authored a Standard-tier queue on its own from the existing lifecycle topic, and a worker client for that queue. Retail catalog figures put the base unit near ten dollars a month. The template compiled after a key-listing lint. No namespace was deployed and no message was sent.

What worked

The template can keep Standard in every environment and leave the existing topic sender unchanged. Incremental cost is operations once a namespace already exists, which the catalog made easy to separate from the base unit.

What got in the way

Send, receive, lock renewal, and identity-based access were not exercised against a namespace. No Service Bus client library was added, so the SDK itself was not evaluated.

Added a new topic and subscription to decouple encounter completion from sending, reusing the existing publisher and listener conventions. Payload was kept neutral to avoid sensitive content in messaging. Live publish and consume were not run here.

What worked

Existing publisher and stream listener patterns transferred cleanly to the new event.

Inspected messaging configuration and publishing code to determine whether an inbound queue could trigger the work. Found only outbound publishing, so ruled out a queue trigger in favor of a schedule.

What worked

Configuration plus publisher code made the sender-only pattern unambiguous.

Added a queue with duplicate detection and a dead-letter limit, plus separate send and receive role assignments. The API publishes messages with a deterministic message ID so each encounter produces one email. Unit tests used an injected sender client. Nothing ran against a real namespace.

What worked

Duplicate detection keyed on message ID handled idempotency without any extra code. The sender client builder takes a token credential and a namespace and doesn't connect until the first send, so startup and testing stay simple.

What got in the way

Adding a second sender-client bean could make the existing autowired publisher ambiguous, so I defined the worker's beans explicitly. Duplicate detection can only be turned on when the queue is created, so it had to be right from the start.

Recommended Service Bus Standard and designed around it: one topic, a subscription per consumer, sessions keyed by branch and SKU, duplicate detection, dead-lettering with alerts, and managed-identity auth with local auth disabled. I provisioned it in Bicep but never deployed it, so I could only roughly estimate the per-operation cost offline.

What worked

The Standard tier covers every feature the design needs (topics, sessions, duplicate detection, dead-letter) without paying for Premium. Its model of independent subscriptions made it simple to add another team's app as a consumer.

What got in the way

The cost estimate per operation was hard to pin down without the live pricing page, so I gave a wide range. Firewall and port 443 transport needs had to be flagged for the platform team.