Why this book, and How to use it
Every software engineer remembers the gap. You finish a course, or a degree, or a bootcamp, and
you can write code, real code, code that compiles and runs. But the first time a colleague hands
you a codebase at work, something is off. The classes are named differently from anything you
studied. There is a layer called a service and another called a repository and a third called a DTO,
and nobody has explained why all three exist when one would seem to do. The database has a
migration history. The commits reference ticket numbers. Pull requests are opened against a branch called develop, not main. The gap between the code you learned to write and the code
professionals write every day is wider than any tutorial warned you it would be.
This book is built to close that gap. Not by simplifying real engineering into toy examples, by
doing it the other way around: taking a real, production-grade banking application and building
every part of it, from the database schema to the React frontend, from JWT authentication to
double-entry ledger writes, with the same discipline a working team would apply. You will not
finish this volume knowing how Spring Boot works in theory. You will finish it having shipped a
full-stack banking application that could, with production credentials and a cloud account, go live.
Why a Banking Application?
The choice of domain was deliberate. Banking is not glamorous, but it is honest. A banking
application cannot hide behind vague requirements or aesthetic excuses. Money is exact: it cannot be a floating-point number, it cannot be lost in a failed transaction, it cannot be transferred to an account that does not exist. These constraints force every engineering decision to be justified. Why do we use BigDecimal instead of double? Because a rounding error in a fund transfer is a regulatory violation, not a display bug. Why do we maintain an idempotency key on every write? Because a network retry must not debit an account twice. Why does the KYC state machine exist as an explicit state machine rather than a boolean flag? Because regulators require a documented, auditable trail of every status change. Banking also touches the full depth of the stack. You will design a relational schema with proper indexing and Flyway migrations. You will write a Spring Boot backend with JWT security, transactional service methods, and a global exception handler. You will build a React 19 frontendwith real API integration, route guards, and document upload. You will connect the two with a CORS-aware security configuration. Nothing is glued together with shortcuts that would have to be unpicked later. By the end of this volume, you will have built: customer registration with KYC verification; login with refresh token rotation and account lockout; account opening with an enforced KYC gate; fund transfers across NEFT, IMPS, UPI, and RTGS channels with double-entry ledger writes; beneficiary management with IFSC validation and a 24-hour cooling period; bill payment with biller timeout handling; standing instructions with a cron scheduler; SMS and email notifications; card management with PCI-DSS-aware encryption; cheque book and stop-cheque workflows; loan disbursement with an amortisation schedule; account statements with PDF and CSV export; and a full admin portal with role-based access control. That is not a list of features in a demo. It is a portfolio.
The Four-Volume Arc
This is the first of four volumes, and understanding where it sits in the series will help you decide
how to use it.
Volume 1 — Banking Core & Full-Stack Foundations (this volume)
Builds the complete monolithic application from zero. Every line of code is explained. Every
architectural decision is motivated. If you are new to Spring Boot, or new to React, or new to
building the two together, start here. By the end, you will own a working, tested, containerised
full-stack application and a GitHub repository that demonstrates professional discipline.
Volume 2 — Enterprise Architecture & Quality Engineering
Takes the same application and raises the standard. Redux Toolkit replaces ad-hoc state
management. Playwright end-to-end tests cover every user journey. Redis caching reduces
database load. Spring Batch handles scheduled financial jobs. SonarQube enforces quality gates in CI. The focus shifts from making it work to making it production-worthy.
Volume 3 — Microservices & Event-Driven Systems
Breaks the monolith apart. The NetBanking application becomes a suite of independently
deployable services communicating over Apache Kafka. Distributed transactions are handled with
the Saga pattern. Resilience4j adds circuit breakers and bulkheads. MongoDB and Redis are
introduced hands-on inside a rebuilt Notification Service. Mutual TLS secures inter-service
communication. This is where the hard parts of distributed systems become concrete.
Volume 4 — Cloud-Native & Production Operations
Deploys everything to Kubernetes. Helm charts manage environment-specific configuration. Istio
provides a service mesh with automatic mTLS, canary deployments, and traffic mirroring. Gatling
runs load tests against five thousand concurrent users. Chaos Engineering game days verify that the system recovers from pod failures. The RBI IT Framework compliance checklist confirms that the system meets Indian banking regulatory requirements. This is senior-engineer territory.
Each volume builds on the one before. The code evolves; nothing is thrown away. The application
you build in Volume 1 is the same application you harden in Volume 2, decompose in Volume 3,
and operate in Volume 4.
