AKHN: marketplace with teams, orders, disputes and documents
Backend development for a marketplace platform: teams, roles, orders, responses, disputes, WebSocket communication, notifications, Handlebars document generation and MinIO file storage.
AKHN was a marketplace for customers and contractors. Users could create teams, publish orders, send responses, communicate, complete work and move into dispute scenarios with additional parties attached to an order.
In projects like this, the risky part is usually not CRUD, but permissions and state. The same user can be a customer, a team lead, a team member or a dispute participant. If access checks are scattered across controllers, the system quickly becomes unpredictable.
My Role
I worked on backend development and the design of key marketplace modules.
Main areas:
- order lifecycle: creation, response, acceptance, execution, completion and dispute;
- team model: lead, members, requisites and team count limits;
- permission checks for responses, order execution and data access;
- notifications through queues and service-to-service communication;
- WebSocket communication with Redis for rooms and participants;
- legal document generation using Handlebars templates;
- document and file storage in MinIO;
- Swagger documentation and DTO validation.
Architecture and Decisions
The backend evolved as a NestJS monorepo split into modules. Redis Pub/Sub and queues were used for event exchange so that notifications and background operations would not block user-facing scenarios.
I kept order logic close to the domain. Statuses, allowed transitions, permissions and side effects should not live in one huge service. This mattered especially for disputes and team collaboration, where access depends not only on a global role, but also on the user's relationship to a specific order.
Non-Trivial Parts
The most sensitive area was the chain “team -> order -> response -> dispute”. For example, not every team member can send a response; only a team lead should do it. Only the assigned team can execute the order. A dispute opens a different set of actions and notifications.
Documents were also part of the business process, not just file attachments. They had to be generated from legal templates, stored securely and protected by access rules.
Result
The project received a backend foundation for a marketplace with teams, orders, disputes, chats, documents and notifications. This case shows my experience with backend systems where the real complexity lives in business rules, not in the number of endpoints.