Fair Parking System — architecture docs and development plan

I’ve been working on a side project called Fair Parking System (FPS) — a multi-tenant SaaS platform that replaces the usual “first-come, first-served” email chaos for parking management with a transparent, algorithm-driven allocation system.

The core idea is a daily Draw process: employees submit parking requests for the next day, and a weighted lottery runs nightly to assign slots fairly. The algorithm gives more weight to those who park least often, so occasional parkers aren’t constantly crowded out by daily commuters.

What’s in the architecture

The system is designed as event-driven microservices on .NET and Kubernetes, with Dapr handling state management, pub/sub messaging, and — most interestingly — Dapr Workflows for the Draw process itself. Long-running, durable orchestration is exactly the right fit for something that needs to lock slots, run an allocation algorithm, persist results, and fire notifications — all while surviving a service restart mid-flight.

Key services: Booking, Identity, Profile, Customer, Billing, Notification, Audit, Reporting, and Configuration. Each follows onion architecture with a pure domain layer that has no infrastructure dependencies, which makes the allocation algorithm straightforward to unit-test in isolation.

The architecture wiki

I’ve published the full architecture documentation — business layer, application layer, technology decisions, and the new development plan — as a Docsify site:

https://www.vejvoda.net/FPS-wiki/

It covers the weighted lottery algorithm, Dapr Workflow design for the Draw process, the phased development plan, and a list of open questions and discrepancies I found while reviewing the docs (including the fact that the original Dapr version listed predates Dapr Workflows by several major releases).

Source on GitHub: RobertVejvoda/FPS-wiki, RobertVejvoda/FPS.code.

• 2026 1
• 2023 3
• 2022 1
• 2021 1
• 2020 1