Engineering decisions

Choose.
Then examine the trade-off.

Good architecture is rarely about selecting the universally best technology. Pick the option you would start with, then compare the decision against context, constraints, and failure modes.

01 / Architecture

Modular monolith or microservices?

A new product has one team, uncertain boundaries, and no unusual scaling requirements. Where would you begin?

My starting point: a modular monolith

With one team and a young domain, a modular monolith keeps feedback fast while boundaries are still being discovered. Strong modules, explicit interfaces, and separate ownership inside the code preserve future extraction paths.

Choose microservices when independent deployment, regulatory isolation, team autonomy, failure containment, or different scaling profiles create enough value to justify distributed data, networking, observability, and delivery complexity. Read the deeper guide to production-ready .NET microservices on Azure.

02 / Quality

Unit tests or integration tests?

A payment rule contains many edge cases, but the service also depends on database mappings and HTTP configuration. Which layer matters more?

My answer: both, aimed at different risks

Use focused unit tests to explore calculations, validation, state transitions, and edge cases quickly. Use integration tests to verify the real HTTP pipeline, configuration, serialization, database engine, migrations, and external contracts.

The useful question is which failure a test is designed to detect. The detailed reasoning is in Unit Testing and Integration Testing: Why You Need Both.

03 / Azure

Azure Container Apps or App Service?

A team has containerized .NET APIs and workers, wants revision-based releases, and does not need direct Kubernetes control.

My likely choice: Azure Container Apps

Container Apps fits containerized APIs and background workers that benefit from revisions, traffic splitting, and event-driven scaling without the operational surface of Kubernetes.

App Service remains a simpler and mature choice for conventional web applications and APIs. Existing team knowledge, networking, deployment tooling, cost, and operational maturity can outweigh a feature comparison.

04 / Integration

Synchronous API or asynchronous messaging?

An order must trigger fulfillment, analytics, and customer communication. The caller only needs confirmation that the order was accepted.

My choice: accept, persist, and publish

Return an immediate response after validating and durably accepting the order, then publish an event for independent consumers. This avoids a long synchronous chain and lets downstream work recover from temporary outages.

Consumers must be idempotent, contracts must be versioned, and dead-letter queues must be monitored. Use a synchronous call only when the caller truly cannot proceed without the downstream answer.