Java backend engineering
SaaS Billing Platform
Subscription, billing, authentication, caching, usage, and payment workflows in Spring Boot.
Java backend implementation and domain modeling
Java · Spring Boot · Spring Security · JWT / RBAC · MongoDB · Redis · Bucket4j
Open-source learning project · mock payments
OVERVIEW
A layered Java backend for plans, subscriptions, invoices, usage records, and mock payment workflows. Spring Security and JWT handle access, service classes own domain operations, and MongoDB repositories persist the current implementation.
Architecture
- 01AUTHENTICATE
JWT filter and role-aware Spring Security rules.
- 02API → SERVICE
Validated requests enter subscription and billing logic.
- 03PERSIST / CACHE
MongoDB repositories; Redis-backed plan caching.
- 04PAYMENT WORKFLOW
Mock orders and payment logs exercise the lifecycle.
BOUNDARYCurrent source uses MongoDB, despite the older README's PostgreSQL/JPA description. Payment adapters are mocks, not verified live payment processing.
Controllers, DTOs, services, and repositories separate HTTP contracts from business operations and storage. The current Maven dependencies and repositories use Spring Data MongoDB; Docker Compose configures MongoDB and Redis.
Spring Security provides a JWT filter and ADMIN/USER access rules. Plan reads are cached and writes evict entries. Bucket4j applies request limits through an interceptor backed by process-local buckets.
Key decisions & trade-offs
Subscription changes, invoice generation, and usage recording have dedicated services. Invoice and payment records carry denormalized fields to support retrieval without assuming relational joins.
Mock payment services make billing flows inspectable without a provider account. Simulated responses and mock signature checks cannot be presented as real payment guarantees.
Verification / results
Source inspection verifies the layered APIs, subscription operations, invoice ownership and amount checks, cache annotations, and role restrictions. Maven declares test dependencies, but the inspected revision has no committed backend test suite.
This case study claims implementation evidence, not test coverage, deployment reliability, or production operation. Automated regression tests and configuration review remain necessary next steps.
Limitations
Payment and signature behavior is mocked. Rate-limit state is local to one process. The README's database instructions are stale, and the inspected revision lacks tracked runtime configuration and a Dockerfile referenced by Compose. The project is not presented as production-grade or as a verified runnable deployment.