spp-backend-patterns

A service layer pattern isolates business logic from controllers by using thin controllers for request handling, dedicated services for logic, and Prisma 7 repositories for data access. This enforces modularity, prevents duplication, and streamlines API delivery.

Idempotent webhook handling for Midtrans workflows uses anti-duplication checks and Prisma transactions to ensure payment events are processed only once. This prevents duplicate invoice entries and maintains financial data integrity during concurrent webhook deliveries.

Implement RBAC through dedicated middlewares and centralize error handling to standardize validation and permission failures across API surfaces. Applying Zod validation ensures robust data integrity for financial actions like invoice generation and student management.

Prisma transactions are required for invoice and payment processing to enforce atomic database updates. They work with anti-duplication checks to guarantee that concurrent billing actions and webhook payloads do not cause data inconsistencies or duplicate records.

Audit logging for financial actions in a school SPP backend provides governance and traceability for sensitive operations. It tracks payment modifications and invoice updates across the service layer, ensuring accountability and simplifying compliance verification.

These backend patterns can be applied across all API surfaces by aligning new modules to the service layer architecture. Using thin controllers, repository-based Prisma data access, and centralized validation ensures consistent, scalable design for any new endpoint.