PRASHANNAGHIMIRE

Key engineering decisions

• Debit first, compensate on failure. The sender is debited synchronously before the fraud decision. If verification fails or the OTP expires, a compensating credit and a transaction.refunded event reverse it. It is a choreographed saga with no central coordinator.
• Fraud checks run off the request path. The transfer request returns after publishing transaction.initiated. Fraud Detection decides asynchronously: clean transfers complete, suspicious ones go through an OTP step.
• Thresholds live in configuration. Transactions per minute, the unusual-amount multiplier and the maximum share of balance are application.yaml properties, so rules change without code changes.
• Services read each other through APIs. Transaction and Fraud Detection get balances from Account through an OpenFeign client instead of reaching into its data.

Why these technologies

Kafka

Asynchronous communication, so fraud checks and notifications do not block a transfer

Redis

Temporary data: OTPs that expire by themselves and per-account counters with a time window

MySQL

Relational, transactional data accessed through JPA

OpenFeign

Declarative synchronous calls where a result is needed immediately

Docker and Kubernetes

Reproducible images per service, with Deployment and Service manifests for each

Implemented features

• Account creation with generated 12-digit account numbers, account status and daily limits
• Transfers with a status lifecycle that includes PROCESSING, PENDING_VERIFICATION, COMPLETED and FLAGGED
• Three fraud checks: velocity, unusual amount against a running average, and share of balance
• OTP verification for flagged transfers, stored in Redis with a 5-minute expiry
• Refund path that credits the sender back and publishes an event for notifications
• Per-service Dockerfile, Kubernetes manifests and a GitHub Actions workflow that builds and pushes the image

Engineering notes

• Money moves before the fraud decision, so the failure path matters as much as the happy path. That is why the compensation step exists.
• Redis does two short-lived jobs: OTPs expire on their own, and a counter with a 60-second expiry drives the velocity check.
• Services never share a codebase. They agree only on topic names and JSON payloads.

Not built yet

• API gateway and service-to-service authentication. The JWT library is a dependency of the account service but is not wired in.
• Idempotent consumers and an outbox for publishing events.
• Refund path not yet exercised end to end: the account service's credit endpoint is still unmapped, so the compensating call from Transaction needs finishing.

Key engineering decisions

• Payment state is explicit. A PaymentStatus enum (CREATED, PENDING, COMPLETED, FAILED, REFUNDED) is stored as a string, and amounts use BigDecimal with fixed precision.
• The webhook drives state changes. Only the Razorpay webhook updates the record and triggers the Kafka event, keyed by payment id.
• Secrets stay out of the repo. Database and Razorpay credentials come from environment variables, and the Kubernetes Deployment loads them from a Secret.

Why these technologies

Kafka

Publishes outcomes so other services react without being called directly

MySQL

Relational storage for payment records

Docker multi-stage build

Maven build stage, slim JRE runtime image

Implemented features

• Request validation with Bean Validation on the create-order endpoint
• Actuator health endpoint for probes
• GitHub Actions workflow that builds the image on push to main and tags it latest and with the commit SHA
• Kubernetes Deployment and Service manifests

Key engineering decisions

• Tenant per clinic. Every clinic is its own tenant, so access and data are scoped per clinic.
• Role-based access control. Permissions are tied to roles, so what a user can do depends on their role within their clinic.
• Prescriptions as a lifecycle. Prescriptions move through draft, issued and cancelled states instead of being edited in place.
• Inventory as a chain. Stock flows from suppliers through purchase orders and goods receipt into batches.

Why these technologies

MongoDB

Document model for tenant-scoped clinical and inventory records

Express

Thin REST layer over the domain logic

Implemented features

• Multi-tenant clinic model
• Role-based access control
• Prescription lifecycle: draft, issued, cancelled
• Inventory: suppliers, purchase orders, goods receipt, batches