Raízes do Nordeste API
REST API for multichannel orders, per-unit inventory, and simulated payments
2026
Context
Raízes do Nordeste is a REST API developed for an academic Back-End Project. It centralizes the operation of a multi-unit restaurant chain: users, catalog, inventory, orders, campaigns, coupons, loyalty, and payments. The technical goal was to connect these resources through consistent business rules instead of treating them as unrelated CRUD modules.
Architecture
The application uses Java 17 and Spring Boot 3.5, separating controllers, services, and repositories. DTOs define the HTTP contract and centralize input validation. JPA and Hibernate provide relational mapping, while Flyway keeps database evolution reproducible. Local development and tests use H2, with configuration also available for PostgreSQL.
Critical flows and consistency
Order creation reserves inventory at the selected unit and applies benefits in the sequence campaign, coupon, and loyalty points. The operation is transactional and accepts an Idempotency-Key, preventing duplicate orders when the same request is retried.
Payments go through a simulated gateway that can approve, decline, or reproduce technical unavailability. A state machine controls order progress, automatic reservation expiration, and cancellation with inventory return, benefit compensation, and refund. Conditional updates and pessimistic locks protect inventory, campaigns, coupons, payments, and cancellations from concurrent conflicts.
States and transitions controlled by the order service.
Security and data protection
Authentication uses JWT and BCrypt-protected passwords. Authorization combines roles with contextual rules such as order ownership and the employee's assigned units. The project also records versioned acceptance of platform terms, separate loyalty consent, account anonymization, and pseudonymized identifiers in logs.
Validation and limits
The solution includes 255 automated tests. Its OpenAPI contract documents 49 operations, and the Postman collection contains 35 chained requests with 55 assertions. As a deliberate limitation, the gateway does not process real financial transactions and the application does not represent a production deployment.