Four domain services make the architecture concrete
The repository splits flight booking into Identity, Flight, Passenger, and Booking services, with YARP as the public gateway. Each domain owns its write model and read model. Most writes use PostgreSQL, Booking uses EventStoreDB, and projections land in MongoDB. RabbitMQ and Wolverine move integration events, while gRPC handles cross-service checks that need a direct answer. This is enough detail to trace one reservation across boundaries rather than stare at an abstract microservices diagram.
The checkout is also compact relative to that scope: our clone contained 579 files, about 19,647 lines of source, and occupied 3.2 MB. Feature folders group an endpoint, command or query, handler, validator, and events around one use case. That makes the vertical-slice idea visible in the tree. Shared building blocks still exist for database access, messaging, logging, resilience, and test support, so the example does not pretend every service is completely isolated.
The stack teaches many patterns at the same time
Booking Microservices combines domain-driven design, CQRS, event sourcing, REST, gRPC, durable messaging, identity, telemetry, and container orchestration. That breadth is useful for an experienced developer asking how the pieces meet. It is punishing for a beginner who still needs to learn which problem each piece solves. A failed request may pass through a gateway, token server, service, broker, event store, projection, and read database before the browser sees it.
The messaging model is specific. Wolverine's outbox aims to deliver published work even after a service interruption, while inbox processing is used to avoid applying the same message twice. Those guarantees depend on configuration and handler behavior, not the diagram alone. The README also names Polly, OpenTelemetry, Jaeger, Prometheus, Grafana, Serilog, Kibana, Redis, and 3 orchestration routes. Each addition is defensible, but together they turn a study session into infrastructure work.
What happened when we ran it
Our sandbox attempted commit 40789dc on September 29 with 3 CPUs, 8 GB of RAM, Node 22, no secrets, and no elevated privileges. Installation failed after 16 seconds with exit code 127. The final log lines show npm running the package's prepare command, husky && dotnet tool restore, followed by sh: 1: dotnet: not found.
That message establishes the missing executable and nothing more. It does not show a broken NuGet restore, a .NET source error, or a service failure. The package file makes Node tooling look like a separate developer convenience, but npm install immediately crosses into the .NET toolchain. A machine that follows only the Node part of the setup cannot finish that command.
Because installation stopped, the lab block contains no build or test outcome. Our scanner reported 2 CI workflow files, no Dockerfile, and no tests directory. Repository inspection clarifies that those last 2 signals apply to the root convention the scanner looked for: service folders contain Dockerfiles and test projects, while the CI workflow invokes a shared build-and-test action for Booking, Flight, Identity, and Passenger. We did not run those projects.
Local execution means running the supporting system too
The documented prerequisites are .NET 10, Docker Desktop, and Node.js, plus a development HTTPS certificate. aspire run is the shortest route and exposes its dashboard on port 18888. Docker Compose can start only infrastructure or the full stack. Integration and end-to-end tests use Testcontainers, so a working Docker daemon is part of the test environment rather than an optional deployment concern.
Infrastructure includes PostgreSQL, MongoDB, EventStoreDB, Redis, RabbitMQ, Jaeger, Zipkin, an OpenTelemetry collector, Prometheus, and Grafana. Add the 4 domain APIs, identity, and the gateway, and this is no longer a lightweight code sample. Before adapting it, decide which components teach something you need. Removing event sourcing or duplicate observability backends may produce a better internal reference than copying the entire topology.
The Kubernetes path needs cert-manager and application manifests, but the README says those manifests reference images in evangelosvlachos96/. You must publish compatible images there or change the names. Aspire and Compose are better first checks because they keep more of the supplied wiring intact. None of the 3 paths removes the need to replace sample passwords, configure secrets, decide persistent volumes, and prove backup and restore behavior.
Published sample credentials should stay inside a lab
The README gives van1 with Admin@123456 and van2 with User@123456 for manual API testing. That is convenient for a local demo and dangerous if a copied deployment reaches a shared network unchanged. IdentityServer, gateway routes, database credentials, message-broker access, certificates, and telemetry endpoints all need a production secret model that the sample credentials do not provide.
API documentation is available from each service through Swagger and Scalar, and a checked-in REST Client file gives developers a quick way to exercise endpoints. Those are good learning aids. They do not replace authorization tests around admin operations or tenant boundaries. A flight-booking system also needs business controls around seat contention, payment, cancellations, and personal data that a reference architecture may only model partially. Judge the domain behavior separately from the architecture vocabulary.
Four commits are too little history for a platform decision
The repository was created on September 5, 2026 and last pushed on September 13. GitHub showed 613 stars, 0 open issues or pull requests, 4 commits, and no published release on September 30. That recent activity means it is not stale. The short history and empty discussion queue mean there is little public evidence about upgrades, bug response, or teams running it beyond the author.
Use Booking Microservices as a map you can walk through, not as a package you install and rename. The service boundaries, vertical slices, event flow, CI wiring, and deployment files give an experienced .NET developer plenty to inspect. Our 16-second install failure proves the entry path assumes more tooling than npm reveals. A production fork should earn its own green build, test results, threat model, image registry, and recovery practice before any architectural pattern gets credit.