vasuantala049/milk-production-and-prediction-system

1. Overall shape

- This is a full-stack dairy management platform with three main layers: a React/Vite frontend, a Spring Boot backend API, and infrastructure/deployment code for AWS + Kubernetes.

- The core business flow is farm operations and milk commerce: manage farms/sheds/cattle, track milk production and inventory, and support customer buying/subscriptions.

2. Frontend: role-based single-page app

- The frontend is a React SPA built with Vite and served behind Nginx.

- It is organized around user roles and workflows: customer, worker, and owner dashboards, plus screens for login/register, forgot password, farm/cattle management, milk entry, subscriptions, orders, and profile management.

- The UI also includes internationalization support for English and Gujarati, a barcode scanner component, and reusable UI primitives.

3. Frontend-to-backend interaction

- The frontend talks to the backend through dedicated API clients for cattle, farm, order, and subscription flows.

- Route protection is handled in the client, so authenticated navigation is a frontend concern, but authorization is ultimately enforced by the backend.

4. Backend architecture: classic layered Spring Boot

- The backend follows a standard Controller → Service → Repository → Entity structure.

- Controllers expose REST endpoints by domain area: auth, user, farm, shed, cattle, milk, buy milk, order, and subscription.

- Services contain business rules; repositories wrap persistence; DTOs isolate API contracts from JPA entities.

5. Core domain model

- The main entities are Farm, Shed, Cattle, MilkInventory, CattleMilkEntry, MilkAllocation, Orders, Subscription, User, and worker/invitation linkage objects.

- The domain is built around operational relationships: farms contain sheds and cattle, cattle generate milk entries, milk is aggregated into inventory and allocated for sale, and orders/subscriptions consume that inventory.

- Worker assignments and invitations indicate multi-tenant, role-scoped access to farm resources.

6. Security and identity

- Authentication is JWT-based, with a custom user-details service and a JWT authentication filter in the request pipeline.

- Password handling uses a bounded bcrypt encoder, and user roles are modeled explicitly in the domain.

- Auth-related APIs support login, registration, forgot-password, and OTP/reset flows, which suggests email-driven account recovery.

7. Persistence and runtime dependencies

- The backend uses a relational persistence layer via Spring Data repositories and JPA entities.

- Redis is a first-class runtime dependency: there is dedicated Redis cache configuration plus a startup check, so the application expects Redis to be available and healthy.

- There is also a database health controller, implying operational readiness/liveness checks are part of the backend surface.

8. Payments and commerce workflows

- The buy-milk, order, and subscription modules are separate, but connected through shared inventory and payment request/response DTOs.

- Razorpay-specific response DTOs indicate external payment-gateway integration for purchase and subscription checkout.

- Orders and subscriptions have explicit status enums, which suggests stateful payment lifecycle handling.

9. Operational support and cross-cutting concerns

- A global exception handler centralizes API error translation.

- Mapper configuration suggests DTO/entity conversion is a formal concern rather than ad hoc mapping.

- Email service implementation supports notification-style workflows such as OTP, password reset, and worker invitations.

10. Deployment and platform

- The repo includes Kubernetes Helm charts for the application stack, with separate templates for backend, frontend, Redis, ingress, namespace, secrets, and autoscaling.

- Nginx ingress is included as part of the platform layer, which means external traffic is routed into the cluster through ingress resources rather than direct pod exposure.

- The frontend also has cert assets and an Nginx config, indicating HTTPS-aware static serving or reverse-proxy deployment.

11. Infrastructure as code and GitOps

- Terraform provisions the AWS environment; the README specifically calls out DB credentials as Terraform inputs, so infrastructure and application bootstrap are meant to be repeatable.

- There are Argo CD and image updater manifests, which points to GitOps-based rollout of container images into Kubernetes.

- CI files for GitHub Actions and Jenkins indicate automated build/test/package pipelines feed the deployment process.

12. How data moves through the system

- Users interact with the SPA, which calls REST endpoints on the Spring Boot API.

- The backend authenticates requests with JWT, reads/writes relational state through repositories, uses Redis for cache or fast access, and emits updates through payment/email flows when needed.

- Deployed services run in Kubernetes behind ingress, with AWS-provisioned infrastructure underneath and image updates managed through CI/CD/GitOps.