A Web-Based Car Wash Booking and Queue Management System
The Web-Based Car Wash Booking and Queue Management System is a software platform designed to improve how car wash services manage customer queues and service availability. Many small car wash businesses rely on manual walk-in systems where customers must physically wait in line without knowing queue length or estimated waiting times. This often results in inefficient service management and poor customer experience.
This system introduces a digital platform that allows customers to view available car wash services, check queue length, and join a service queue remotely. At the same time, car wash businesses can manage service queues, update job statuses, and monitor daily workload through a centralized interface.
The purpose of this project is to design and demonstrate a digital system that improves queue visibility and operational efficiency for car wash businesses. The system will provide a structured way for customers and service providers to interact through a web-based platform.
The project is being developed as part of the Software Engineering System Specification and Architectural Modeling assignment, where the system will be fully documented and modelled using the C4 architectural model.
The system aims to:
- Provide customers with visibility into available car wash services
- Allow customers to join or schedule service queues digitally
- Enable car wash businesses to manage bookings and service flow
- Improve operational efficiency and customer experience
- Demonstrate a scalable system architecture that can support future expansion
The initial system prototype will support:
- Customer registration and login
- Vehicle registration
- Car wash business registration
- Service listing and pricing management
- Digital queue and booking management
- Service status updates
- Customer ratings and feedback
Follow these steps to set up the project locally for development, testing, or contribution.
git clone https://github.com/ongeziwe17/carwash-booking-queue-system.git
cd carwash-booking-queue-system./mvnw clean package./mvnw spring-boot:runAfter starting the Spring Boot application, open Swagger UI at:
http://localhost:8080/swagger-ui/index.html
OpenAPI JSON is available at:
http://localhost:8080/v3/api-docs
Start with one of our beginner-friendly issues:
Issues marked with code 'Contr-:'
- good-first-issue
- help-wanted
- enhancement
View Issues:
https://github.com/ongeziwe17/carwash-booking-queue-system/issues
| Area | Difficulty | Suggested Label |
|---|---|---|
| Input Validation Improvements | Beginner | good-first-issue |
| API Pagination | Beginner | good-first-issue |
| Audit Logging | Intermediate | feature-request |
| JWT Authentication | Intermediate | feature-request |
| Redis Caching | Advanced | feature-request |
| Kubernetes Deployment | Advanced | feature-request |
This repository is an open-source learning project for building a practical web-based car wash booking and queue management system. The project has already attracted community interest with 19 stars and 21 forks, and contributions are welcome from reviewers, and external contributors.
This repository was prepared using open-source collaboration practices.
The project includes:
- contribution guidelines
- roadmap documentation
- issue labeling strategy
- CI/CD automation
- onboarding documentation
Community engagement metrics:
| Metric | Count |
|---|---|
| Stars | 19 |
| Forks | 21 |
Contributions, suggestions, and peer reviews are welcome.
Files included:
- Contribution
- Roadmap
- Licence
- VOTING-RESULTS.md
- Reflection
Screenshots:
documentation/screenshots/peer-review/
Detailed system documentation and architecture diagrams are available in the following files:
- System Specification
- System Architecture
- Stakeholder Analysis
- System Requirements
- Reflection
- Use Case Diagram
- Use Case Specifications
- Test Case Development
- Agile User Stories
- Product Backlog
- Sprint Planning
- Template Analysis
- Kanban Explanation
- Object State Modeling
- Activity Workflow Modeling
- Traceability Mapping
- Domain Model
- Class Diagram
- Repository Class Diagram
- Branch Protection Rules
- Contribution
- Roadmap
- Licence
The system will be developed using the following technologies:
Core Application
- Backend / API: Java Spring Boot
- Database: PostgreSQL
- Frontend: Vue.js or React (Web-based interface)
DevOps and Deployment (Optional Extension)
- Containerization: Docker
- Infrastructure Provisioning: Terraform
- Cloud Hosting: AWS
- CI/CD: GitHub Actions
Architecture Modeling
- C4 Model using Mermaid diagrams
For Class Diagrams to Code with All Creational Patterns, Java 21 and Spring Boot with Maven were selected because they align with the planned backend and API implementation approach for this system. The implementation work translates the Domain Modeling and Class Diagram Development Mermaid class diagram into concrete Java classes in the project domain model. In addition, all required creational design patterns were implemented to demonstrate multiple object-creation strategies in a domain-relevant way. Unit tests were added to validate these pattern implementations and support maintainable evolution of the codebase.
src/main/java/com/carwash/
├── domain/
├── enums/
└── creational_patterns/
├── simple_factory/
├── factory_method/
├── abstract_factory/
├── builder/
├── prototype/
└── singleton/
| Pattern | Implementation | Purpose |
|---|---|---|
| Simple Factory | VehicleFactory | Centralizes creation of vehicle-type objects |
| Factory Method | Notification sender factories | Delegates notification sender creation to concrete factories |
| Abstract Factory | Dashboard component factories | Creates related role-based dashboard component families |
| Builder | BookingBuilder | Builds booking objects step-by-step with validation |
| Prototype | ServicePrototypeRegistry | Clones reusable service templates |
| Singleton | ApplicationConfig | Provides one shared application configuration instance |
Although not every creational pattern would be required in a small MVP, all six patterns were implemented because Class Diagrams to Code with All Creational Patterns requires them. Each pattern was adapted to the car wash booking and queue management domain where possible.
Run unit tests:
mvn clean test
Generate unit test coverage report:
mvn clean test jacoco:report
Coverage report output:
target/site/jacoco/index.html
Class Diagrams to Code with All Creational Patterns implementation and testing tasks were tracked using GitHub Issues. Related issues were moved through the GitHub Project Kanban workflow as work progressed. Completed implementation and testing items should be moved to Done where applicable, and any defects or improvements identified during testing should be captured as new issues for follow-up.
In-Memory Repository Layer
HashMap-based in-memory repository implementations were added for the repository interfaces in com.carwash.repository.
- A reusable generic
InMemoryRepository<T, ID>base class for shared CRUD behavior. - Entity-specific in-memory repositories for
User,Role,Vehicle,Service,Booking,QueueEntry, andNotification. - CRUD support (
save,findById,findAll,delete) withOptionalforfindByIdand defensiveListcopy return forfindAll. - Interface-specific finder methods implemented in-memory where domain relationships are available.
- Supports fast development and unit testing without database dependencies.
- Keeps persistence concerns behind repository interfaces.
- Allows easy replacement with filesystem/database/API persistence implementations later without changing service/domain consumers.
You can inspect how the in-memory HashMap is being used during runtime:
InMemoryUserRepository repo = new InMemoryUserRepository();
repo.save(user);
// immutable snapshot (safe for debugging)
Map<String, User> snapshot = repo.storageSnapshot();
// string rendering of current map entries
String view = repo.storageAsString();
// direct console print
repo.printStorage();
This is useful for debugging CRUD flows without any database connection.
For this section, the Factory Pattern was selected to implement storage abstraction because it clearly demonstrates how repository implementations can be switched between storage backends.
Application code now depends on repository interfaces (for example, UserRepository) rather than concrete HashMap-based classes. The factory controls which implementation is returned.
Current supported backend:
MEMORY
Planned future backend options:
DATABASEFILESYSTEMAPI
Any unsupported storage type currently throws UnsupportedOperationException, making unsupported options explicit while keeping the interface stable.
This approach improves separation of concerns, testability, and future scalability. Dependency Injection can still be introduced later when integrating with Spring services, but the Factory Pattern was chosen here because it is simple, explicit, and aligns with the assignment scope.
Example usage:
UserRepository userRepository =
RepositoryFactory.getUserRepository(StorageType.MEMORY);The repository layer is designed so that storage backends can be swapped without changing business logic. Application code depends on repository interfaces, and each backend provides concrete implementations of those same contracts.
- In-memory repositories are currently implemented for fast testing and simple persistence.
- A database-backed repository stub (
DatabaseUserRepository) was added to demonstrate how future persistence can be introduced. - The factory abstraction already includes future storage types such as
DATABASE,FILESYSTEM, andAPI. - Future implementations can replace in-memory repositories by implementing the same repository interfaces.
- The updated repository class diagram documents this extension point.
A service layer has been introduced between future controllers and the repository layer.
- Services now host business rules and validation logic.
- Repositories remain responsible for persistence operations.
- Current MVP service coverage includes: User, Vehicle, Service, Booking, and QueueEntry.
- Role remains a supporting access-control concept and is not implemented as a separate service in this task.
REST controllers were added for User, Vehicle, Service, Booking, and QueueEntry. Controllers delegate to service-layer classes (no business logic in controllers) and currently run on in-memory repositories.
| Entity | Base Endpoint | Supported Operations |
|---|---|---|
| User | /api/users |
CRUD |
| Vehicle | /api/vehicles |
CRUD |
| Service | /api/services |
CRUD, activate/deactivate |
| Booking | /api/bookings |
CRUD, confirm/cancel |
| QueueEntry | /api/queue-entries |
CRUD, call/start/complete |
Swagger UI is available after running the Spring Boot application:
http://localhost:8080/swagger-ui/index.html
OpenAPI JSON:
http://localhost:8080/v3/api-docs
See: API Documentation
Swagger UI screenshots: Swagger UI Screenshots
