From Services to Runtime

A microservice architecture does not become real when services are drawn as boxes on a diagram.

It becomes real when each service owns its truth, protects its invariants, publishes stable contracts, survives duplicate messages, exposes meaningful health signals, fails without corrupting the system, and can be deployed, observed, migrated, and recovered independently.

From Services to Runtime is an architecture and implementation blueprint for turning the NEXUS-1 service model into a disciplined microservice runtime built around .NET, service-owned data, asynchronous messaging, explicit contracts, operational evidence, and controlled failure.

This book begins where high-level microservice discussions usually stop.

It does not merely ask which services should exist. It asks the harder engineering questions:

• Who owns each business fact?
• Which service is allowed to write which data?
• What must remain transactionally consistent?
• What happens when a message is delivered twice?
• How is an unknown commit outcome handled safely?
• When is eventual consistency acceptable?
• How does the user interface communicate delayed truth?
• Which health check proves that a service is actually ready?
• How are migrations, credentials, retries, rollback, recovery, and shutdown controlled?
• What evidence would justify the claim that the runtime behaves as designed?

The book develops a bounded reference slice around three service owners:

• AlarmManagement, which owns alarm observations and alarm-flood decisions.
• RootCause, which owns root-cause cases, evidence, and verdicts.
• Reporting, which owns derived projections, checkpoints, and freshness-bearing reporting truth.

A Query BFF provides the controlled synchronous edge, while public facts connect the owners asynchronously.

Through this slice, the reader follows the complete engineering path from domain decision to runtime effect:

• aggregates and invariants,
• application commands and outcomes,
• service-owned databases,
• EF Core mappings and provider-backed transactions,
• inbox and outbox patterns,
• idempotent consumers,
• public event contracts and versioning,
• delayed projections,
• authentication and authorization,
• startup, liveness, and readiness,
• observability and distributed tracing,
• failure injection and recovery,
• migration and rollback,
• Docker Compose and Kubernetes delivery,
• architecture, component, contract, integration, and runtime tests.

The purpose is not to present isolated patterns. It is to show how the patterns constrain one another inside one coherent distributed system.

The wider NEXUS-1 estate is described as containing 654 tables across 17 schemas.

This book does not pretend that 654 tables imply 654 services—or that 17 schemas imply 17 bounded contexts. Database structure is treated as evidence to investigate, not as a ready-made service map.

The three-owner reference slice demonstrates a migration and implementation method. It does not claim to be the final decomposition of the entire legacy estate.

Before any additional service can be admitted, the book requires evidence about business capability, invariants, write authority, transaction boundaries, identity lifecycle, failure isolation, security responsibility, operational ownership, and migration cost.

Unknown remains an acceptable engineering state. Invented certainty does not.

Many microservice books describe the desired architecture after all difficult decisions appear to have been made.

This book keeps those decisions visible.

It connects architecture to concrete implementation responsibilities and repeatedly asks what would falsify each claim. Code listings, database mappings, configuration examples, contract definitions, deployment manifests, tests, failure scenarios, and evidence records are presented as parts of the same engineering argument.

Throughout the book, the reader encounters a consistent progression:

1. The engineering problem — the runtime risk that must be controlled.
2. The architectural decision — the boundary or responsibility being established.
3. The implementation shape — C#, EF Core, SQL, messaging, configuration, or deployment material.
4. The failure model — what delay, duplication, timeout, partial progress, or restart can do.
5. The test or evidence obligation — what must be observed before a stronger claim is permitted.
6. The honest verdict — what is specified, illustrated, implemented, executed, demonstrated, deferred, or not claimed.

This makes the book useful not only as a guide to microservices, but also as a method for reasoning about distributed systems without hiding their uncertainty.

This book is written for:

• experienced .NET developers moving beyond CRUD-oriented service design,
• software and solution architects,
• backend and distributed-systems engineers,
• database engineers working on service ownership and migration,
• technical leads responsible for delivery and operational quality,
• engineers designing message-driven systems,
• advanced readers who want to connect DDD, testing, infrastructure, security, observability, and failure recovery into one coherent method.

The reader does not need prior knowledge of nuclear engineering. NEXUS-1 provides the demanding industrial context, but the architectural lessons apply to any system in which truth, authority, failure, delayed consistency, traceability, and recovery matter.

From Services to Runtime is a definitive book artifact and a complete architecture and implementation blueprint. It is not presented as a completed software implementation.

The microservice reference application described by the book has not been implemented as an admitted repository and runtime. Restore, compilation, automated tests, database migrations, container execution, broker behavior, failure campaigns, and end-to-end runtime reproduction have therefore not been executed for that future application.

The listings define intended responsibilities and falsifiable acceptance obligations. They must not be mistaken for retained execution evidence.

The existing NEXUS-1 Phase-0 demonstrator can be explored in the browser, but it does not constitute proof that the microservice runtime specified in this book has already been built:

Explore the NEXUS-1 Phase-0 demonstrator:
https://gregory82gr.github.io/Nexus-1-phase-0/

Supporting material and project artifacts are published with the wider NEXUS-1 work:

Project repository:
https://github.com/gregory82gr/Nexus-1-phase-0

NEXUS-1 remains an educational Phase-0 demonstrator. It is not safety-class software, certified operational guidance, or a system connected to any real industrial or nuclear facility.

This book is dedicated to the woman who devoted her life to me. I can only dedicate this book to her—to my wife, Vladimirka.

This book does not promise that microservices make systems simple.

It promises something more useful: a disciplined way to decide where complexity belongs, who owns each truth, how failure is contained, how recovery is designed, and what evidence must exist before architecture is allowed to become a runtime claim.

Nothing claims to exist that does not.

Author: Grigorios Kyriakos Agathangelidis.

Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης.

Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.