Civil Servant Relocation Matching
BECAYIS
A software engineering capstone exploring how optimization could support relocation matching for Turkish civil servants.
The problem
In Türkiye, civil servants can relocate by swapping posts with a colleague who wants the reverse move, a process called becayiş. Finding a compatible partner by hand is slow, and the search gets harder once preferences and constraints stack up.
BECAYIS (Biomimetic AI Supported Permutation Application) was my undergraduate capstone at Bahçeşehir University. Our team designed a relocation matching platform concept where civil servants describe where they are, where they want to go, and what they need, and the system proposes swap candidates.
We explored nature-inspired (biomimetic) optimization, particle swarm and ant colony optimization, as ways to search for good matches when preferences and constraints make a simple lookup insufficient.
Constraints
- Matches had to respect hard constraints as well as softer preferences.
- The product and its documentation needed to work in Turkish and English.
- As a capstone, the work was scoped to a prototype and its design documentation, not a production service.
My role
- Focused on the intelligent matching approach and the biomimetic optimization behind it.
- Worked on backend logic and database planning for the matching flow.
- Integrated the matching logic with the rest of the system through APIs, with system usability in mind.
The React frontend, Spring Boot services, database design, and the project documentation (PDD, SDD, and UML) were team efforts.
System design
The optimization work ran as a Python component behind an API, so the Java backend could request matches without owning the search logic.
- CollectUsers enter current post, desired locations, and constraints in the React app.
- StoreSpring Boot validates requests and stores them in PostgreSQL.
- SearchThe Python service explores candidate matches with PSO and ACO.
- ReturnRanked candidates go back through the API to the user.
Tradeoffs
Metaheuristics instead of exact matching
Why Two-person swaps are easy to find directly, but preference scoring across many constraints grows quickly. PSO and ACO let us explore good candidates within a time budget.
Cost Neither method guarantees the best possible match, so results need to be presented as suggestions.
A separate Python optimization service
Why Python’s numeric tooling made it faster to experiment with search methods.
Cost A second runtime adds an integration boundary, which is the part I worked on through APIs.
What I can show
Synthetic illustration
The visual uses made-up cities and requests to show how preferences and constraints shape a match. It does not represent real people or records.
Design documentation
The team produced a project definition document, a software design document, and UML models.
What I would explore next
- Benchmark PSO and ACO against an exact baseline on the same synthetic dataset.
- Extend matching from pairs to multi-person swap chains.