DEV Community: Shitanshu Jha

ShopEase — Module 32: Concurrency, Multithreading & Database Locking

Shitanshu Jha — Sun, 04 Oct 2026 02:58:16 +0000

As ShopEase moved toward a more production-oriented backend, one important problem needed to be solved:

What happens when multiple users try to purchase the same product at exactly the same time?

In a normal single-user test, stock deduction looks simple. But in a real e-commerce system, multiple requests can reach the backend simultaneously and try to update the same inventory.

That creates a serious problem: overselling.

For Module 32, I focused on multithreading, concurrent stock updates, optimistic locking, pessimistic locking, and atomic stock deduction.

⚡ The Problem: Concurrent Stock Updates

Suppose a product has:

Stock = 10

Now imagine 50 users trying to purchase that product simultaneously.

Without proper concurrency control, multiple threads could read the same stock value before any of them updates it.

For example:

Thread 1 → reads stock = 1
Thread 2 → reads stock = 1

Thread 1 → deducts stock
Thread 2 → deducts stock

Both threads may believe that the product is available.

This is a classic race condition, and in an e-commerce system it can result in selling more units than actually exist.

🧵 Multithreading & Stress Testing

To reproduce this situation instead of relying on normal sequential testing, I introduced concurrent stress testing.

I used 50 concurrent threads attempting to perform stock-related operations.

The purpose wasn't simply to make multiple threads run at once.

The real objective was to verify whether the database and application could correctly handle simultaneous requests accessing the same inventory.

This made the concurrency problem much easier to observe and debug.

🔒 Pessimistic Locking

For pessimistic locking, I implemented:

LockModeType.PESSIMISTIC_WRITE

in the ProductRepository.

The idea is straightforward:

When one transaction is modifying a product row, other transactions shouldn't be allowed to simultaneously modify that same row.

I also configured the MariaDB dialect so Hibernate could generate the appropriate database-level row locking behavior using FOR UPDATE.

Conceptually, the flow becomes:

Transaction 1
↓
Lock Product Row
↓
Check Stock
↓
Deduct Stock
↓
Commit
↓
Release Lock

Another transaction attempting to modify the same row has to wait until the existing lock is released.

This provides strong protection for critical inventory updates.

🧠 Optimistic Locking

I also tested optimistic locking using JPA's:

@version

Instead of immediately locking the database row, optimistic locking assumes that conflicts are relatively uncommon.

Each update checks whether the entity version is still the expected version.

If another transaction has already modified the row, the version changes and the conflicting update can be detected.

Conceptually:

Thread 1 → Version 5 → Update → Version 6 ✅

Thread 2 → Version 5 → Update
↓
Version mismatch ❌

This approach is useful when you want to detect concurrent modifications without holding database locks throughout the transaction.

🛡️ Atomic Stock Deduction

Locking alone isn't the complete solution.

The actual stock operation also needs to be handled carefully so that the availability check and deduction happen safely within the transaction.

The goal was:

Check stock
↓
Stock available?
↓
Atomic deduction
↓
Commit

If sufficient stock isn't available, the purchase must fail rather than allowing the stock value to become invalid.

🧪 50-Thread Concurrent Testing

After implementing both approaches, I performed concurrent testing with 50 threads.

The tests were used to verify:

Concurrent access to the same product
Optimistic locking conflicts
Pessimistic row locking
Atomic stock deduction
Collision handling
Prevention of negative stock
Prevention of overselling

The final result was zero overselling during the concurrent stress tests.

🔍 What I Learned

This module changed the way I think about backend development.

A piece of code can work perfectly when one request executes at a time and still fail when multiple requests execute simultaneously.

Concurrency introduces problems such as:

Race conditions
Lost updates
Concurrent modification conflicts
Database locking
Transaction boundaries
Thread synchronization

The important lesson was:

Correctness in a backend isn't only about what happens during one request. It's also about what happens when many requests happen at the same time.

Module 32 gave ShopEase practical protection against one of the most important problems in e-commerce systems: selling inventory that doesn't actually exist.

Tech Stack

Java • Spring Boot • Spring Data JPA • Hibernate • MariaDB • Multithreading • Optimistic Locking • Pessimistic Locking • Transactions

Java #SpringBoot #Concurrency #Multithreading #Database #Hibernate #MariaDB #JPA #OptimisticLocking #PessimisticLocking #BackendDevelopment #ShopEase

ShopEase: Advanced Backend Features with Webhooks, GraphQL, gRPC & Load Balancing

Shitanshu Jha — Sat, 03 Oct 2026 15:28:16 +0000

In Modules 30.12–30.15, I worked on four advanced backend concepts:

💳 Payment Webhooks
🔎 GraphQL Integration
⚡ gRPC Communication
⚖️ Load Balancing

These modules helped me understand how real-world backend systems handle payment events, flexible data fetching, high-performance service communication, and distributed traffic.

💳 Module 30.12 — Payment Webhooks

Payment processing doesn't end when a user completes a payment.

A payment provider can send asynchronous updates about events such as payment success, failure, or other payment-status changes.

For ShopEase, I implemented the payment webhook flow using Razorpay, including:

Webhook endpoint
Payment event handling
Webhook signature verification
Payment success/failure processing
Idempotent webhook handling

One of the important challenges here was avoiding duplicate processing.

A webhook can potentially be delivered more than once, so the backend needs to make sure the same payment event doesn't accidentally update an order multiple times.

This introduced an important production concept:

Receiving an event is not enough — the system must process it safely.

🔎 Module 30.13 — GraphQL Integration

The next challenge was handling situations where clients don't always need the complete response returned by a traditional REST endpoint.

I integrated GraphQL into ShopEase to understand a different approach to API communication.

With GraphQL, the client can request the specific fields it needs instead of depending entirely on predefined response structures.

This helped me understand concepts such as:

Queries
Mutations
Schemas
Resolvers
Flexible data fetching

The main learning was understanding the difference between simply creating an API and designing an API that gives the client more control over the requested data.

⚡ Module 30.14 — gRPC Communication

For service-to-service communication, I also explored gRPC.

Unlike traditional REST communication, gRPC uses Protocol Buffers and is designed for efficient communication between distributed services.

I worked with concepts including:

gRPC services
Protocol Buffers
Service definitions
Client-server communication
Internal microservice communication

One of the challenges was understanding the complete flow:

Client → Stub → gRPC Service → Response

This gave me a practical understanding of why technologies such as gRPC can be useful for communication between internal microservices.

⚖️ Module 30.15 — Load Balancing

As the number of services and requests increases, sending every request to a single instance can become a bottleneck.

That's where load balancing becomes important.

In this module, I worked with the concept of distributing incoming requests across multiple service instances.

The basic flow becomes:

Client → Load Balancer → Service Instance

instead of:

Client → Single Service Instance

This introduced concepts around:

Multiple service instances
Request distribution
Service discovery
Scalability
Handling increased traffic

The biggest takeaway was that scalability isn't simply about making one server more powerful. A distributed system can instead use multiple instances and distribute the workload between them.

🧠 What These Modules Taught Me

Modules 30.12–30.15 moved ShopEase beyond basic backend development and into more advanced distributed-system concepts.

I worked with four different problems:

Problem Technology
Handling asynchronous payment updates Razorpay Webhooks
Flexible API data fetching GraphQL
Efficient service communication gRPC
Distributing traffic across instances Load Balancing

Each technology solved a different problem, but together they helped me understand an important part of backend engineering:

A production-ready backend isn't just about making features work. It's also about how the system communicates, handles failures, processes events, and scales under load.

There is still more to explore in ShopEase, particularly around deployment, concurrency, fault tolerance, monitoring, and production configuration.

But completing these modules was another significant step in turning ShopEase from a simple e-commerce backend into a more scalable and distributed system.

Tech Stack

Java • Spring Boot • Microservices • Razorpay • GraphQL • gRPC • Protocol Buffers • Load Balancing

Java #SpringBoot #Microservices #GraphQL #gRPC #Razorpay #BackendDevelopment #ShopEase #DistributedSystems #Scalability

Module 30.11 — Microservices Integration & Testing | ShopEase

Shitanshu Jha — Sat, 03 Oct 2026 15:12:37 +0000

💳 Implementing Razorpay Webhooks in Spring Boot 🚀 Real Problems I Faced & How I Solved Them

Shitanshu Jha — Tue, 15 Sep 2026 04:53:59 +0000

Building a payment integration is easy in a tutorial.
Making it actually work is where the real engineering begins. 😅

While working on my ShopEase e-commerce project, I reached a point where payment creation and verification were already working. The next challenge was handling Razorpay Webhooks and processing payment events asynchronously.

🏗️ My Payment Architecture

ShopEase uses a microservices-based backend, with a separate payment-service running on port 8085.

🔄 Before Webhooks
🛒 Frontend
↓
🌐 API Gateway
↓
💳 Payment Service
↓
💰 Razorpay
⚡ After Adding Webhooks
💰 Razorpay
↓
🔔 Webhook
↓
💳 Payment Service
↓
🔐 Verify Signature
↓
🔎 Identify Event
↓
🗄️ Update Payment
↓
💾 Store Event ID
😵‍💫 Challenge #1 — Duplicate Webhooks

One of the first things I realized was that a webhook may be delivered more than once.

If I process the same event twice, I could accidentally execute the same business logic multiple times.

So I introduced a webhook_events table and stored the webhook's eventId.

🔐 Why?
Webhook received
↓
Already processed?
↙ ↘
YES NO
↓ ↓
Ignore Process
↓
Save Event ID

This gave my webhook processing idempotency.

🔑 Challenge #2 — Webhook Secret ≠ API Secret

This one was important.

I learned that the Razorpay Webhook Secret is different from the Razorpay API Key Secret.

Instead of hardcoding the secret, I kept it in an environment variable:

razorpay.webhook.secret=${RAZORPAY_WEBHOOK_SECRET}

🔒 Never put actual secrets directly into your GitHub repository.

🛡️ Challenge #3 — Verifying the Webhook Signature

I couldn't simply trust every request that reached my endpoint.

The request contains:

X-Razorpay-Signature

I used Razorpay's signature verification mechanism with the raw request payload and my webhook secret.

📨 Incoming Request
↓
🔐 Extract Signature
↓
🧮 Generate/Verify HMAC
↓
Valid? ────── No → ❌ Reject
↓
Yes
↓
✅ Process
🚫 Challenge #4 — The Mysterious 403 Forbidden

This was one of those errors where I initially thought:

"Controller mein hi kuch problem hai." 😅

But the controller wasn't the problem.

Spring Security was blocking the request.

My normal APIs require authentication, but Razorpay's webhook doesn't have my application's JWT.

So I specifically permitted:

.requestMatchers("/payments/webhook").permitAll()

and disabled CSRF for the API.

💡 Lesson

A perfectly written controller is useless if security blocks the request before it reaches the controller.

🧪 Challenge #5 — Testing Without Razorpay

While testing locally through Postman, I initially didn't have the real Razorpay signature.

A fake signature such as:

test-signature

correctly resulted in:

401 Unauthorized

And honestly, that was good news. 😂

It meant my signature verification was actually doing its job.

So I created a Postman Pre-request Script to generate the HMAC-SHA256 signature automatically whenever I changed the webhook payload.

🫠 Challenge #6 — "Payment Record Not Found"

This was probably one of my most interesting debugging moments.

The signature was valid ✅
The event was recognized ✅

But:

{
"success": false,
"message": "Payment record not found"
}
🔍 Root Cause

The Razorpay Order ID didn't match the Order ID stored in my database.

It was literally a tiny character difference. 😭

Postman:
order_TT9CFIQhKkyXwR

Database:
order_TT9CFlQkHkyXwR

For humans, they look almost identical.

For a database?

Completely different values. 💀

After correcting the Order ID, the webhook successfully found the payment.

🐳 Challenge #7 — XAMPP vs Docker MySQL

This one caused a lot of confusion.

My application was using:

localhost:3308

while I was checking MySQL through XAMPP/phpMyAdmin on:

localhost:3306

I eventually discovered that port 3308 was actually mapped to my Docker MySQL container:

Windows :3308
↓
🐳 Docker
↓
MySQL :3306

The container was:

shopease-mysql
mysql:8.4
0.0.0.0:3308 → 3306

So instead of trying to move XAMPP to port 3308, I connected directly to the Docker MySQL container.

🧠 Biggest Lesson Here

Before changing a port, first find out which process is already using it.

✅ Testing payment.captured

After fixing the database issue, I tested:

payment.captured

The webhook returned:

{
"success": true,
"message": "Webhook signature verified",
"event": "payment.captured"
}

with:

HTTP 200 OK

More importantly, I didn't stop at the API response.

I checked the database and confirmed:

CREATED
↓
SUCCESS

That confirmed the actual business logic worked, not just the HTTP response.

🔁 Testing Idempotency

Then came the real test.

I sent the exact same webhook again using the same event ID.

Instead of processing it again, the application returned:

{
"success": true,
"message": "Webhook already processed",
"event": "payment.captured"
}

🎯 Duplicate processing successfully prevented!

❌ Testing payment.failed

I also tested:

payment.failed

The webhook was successfully processed and the database payment status changed to:

FAILED

So both major payment events were working:

Event Result
💰 payment.captured ✅ SUCCESS
❌ payment.failed ✅ FAILED
🔁 Duplicate event ✅ Blocked
🔐 Invalid signature ✅ Rejected

🏁 Final Architecture
💰 Razorpay
│
│ 🔔 Webhook
↓
POST /payments/webhook
│
↓
🛡️ Spring Security
│
↓
🔐 Signature Check
│
↓
🔎 Event Detection
↙ ↘
payment.captured payment.failed
↓ ↓
Find Payment Find Payment
↓ ↓
SUCCESS FAILED
↘ ↙
↓
🔁 Check Event ID
↓
Already Processed?
↙ ↘
YES NO
↓ ↓
Ignore 💾 Save Event
↓
✅ 200 OK

🧠 What This Actually Taught Me

The biggest lesson wasn't just "how to implement Razorpay Webhooks."

It was learning how to debug a complete backend system.

🔐 1. Security matters

A controller can't help if Spring Security blocks the request.

🎯 2. IDs must match exactly

A single character difference can break a database lookup.

🐳 3. Understand your infrastructure

Docker port mapping can completely change where your application is actually connecting.

🔁 4. Webhooks must be idempotent

The same event shouldn't execute your business logic multiple times.

🗄️ 5. Verify the database

200 OK doesn't necessarily mean your business logic worked.

🐛 6. Debugging is part of development
💻 Code
↓
🧪 Test
↓
❌ Error
↓
🔎 Find Root Cause
↓
🔧 Fix
↓
🧪 Test Again
↓
🗄️ Verify Database
↓
✅ Done

🚀 Current Status

My Razorpay Webhook implementation currently supports:

✅ Webhook endpoint
✅ Signature verification
✅ payment.captured
✅ payment.failed
✅ Payment status updates
✅ Duplicate webhook detection
✅ Idempotent processing
✅ Database verification

The next step is to extend the webhook flow beyond payment status updates and connect it with the complete post-payment business logic, such as order confirmation and cart clearing.

💡 Final Takeaway

Implementing Razorpay Webhooks taught me something important:

Real-world backend development isn't just about writing code. It's about understanding what happens when that code meets security, databases, infrastructure, external APIs, and unexpected errors.

The most valuable part of this implementation wasn't simply making the webhook work.

It was debugging:

403 errors → invalid signatures → incorrect Order IDs → Docker/MySQL conflicts → duplicate events → database verification. 😎🔥

And that's what made this feature much more realistic than simply following an integration tutorial.

🛒 ShopEase — Payment Service
💳 Razorpay Webhook Integration 🚀

Learn → Build → Break → Debug → Fix → Improve. 💻🔥

From Monolith to Microservices: My ShopEase Backend Journey

Shitanshu Jha — Wed, 09 Sep 2026 08:26:11 +0000

From Monolith to Microservices: My ShopEase Backend Journey

When I started building ShopEase, my main goal was to learn Java backend development by building a real e-commerce application instead of learning concepts only through small examples.

As the project grew, the backend started containing multiple business responsibilities such as products, users, authentication, carts, orders, payments, and more.

At that point, I started exploring an important question

What happens when a growing monolithic application needs to become more scalable and maintainable?

That led me to Microservices Architecture.

What I Had Before

ShopEase initially followed a monolithic backend architecture.

Different business modules were part of the same Spring Boot application:

ShopEase Backend

│

├── User

├── Product

├── Cart

├── Order

├── Authentication

├── Payment

└── Other Modules

Everything was running inside one application.

This architecture is perfectly useful while developing and learning, but as an application grows, managing every business domain inside one large codebase can become increasingly difficult.

So I decided to start exploring a microservices-based architecture.

Starting the Microservices Migration

For Module 30, I started transforming ShopEase from a monolithic backend toward a Microservices Architecture.

My current progress is:

30.1 Microservices Architecture ✅

30.2 Product Service ✅

30.3 User Service ⏳

The first major step was separating the Product Service from the main backend.

Product Service

The Product Service is responsible for product-related functionality.

Instead of keeping product functionality tightly coupled with every other business module, it can now be treated as an independent service.

Conceptually:

        ShopEase
           │
  ┌────────┴────────┐
  │                 │

Product Service User Service
│
Product DB

The idea is that each service should have a clearly defined responsibility.

For example:

Product Service

Products Categories Product Details Product Operations

while the future User Service will handle responsibilities related to users.

Why Microservices?

The biggest thing I'm learning is that microservices are not simply about splitting one project into multiple folders.

The architecture introduces completely different engineering considerations:

Service boundaries

Independent deployment

Service-to-service communication

Data ownership

Failure handling

Scalability

API design

Authentication between services

Monitoring and debugging

This is one of the reasons I wanted to implement the architecture inside ShopEase rather than learning it only theoretically.

What I Learned So Far

One important lesson from this module is that architecture changes introduce new problems.

In a monolith, calling another module may simply mean calling a Java method.

With microservices, that communication may happen through a network request.

That changes the way we think about:

Method Call

↓

HTTP/API Communication

↓

Another Service

This introduces concepts that I am now starting to explore more deeply.

What's Next?

The next step in my ShopEase microservices journey is:

Product Service ✅

↓

User Service ⏳

↓

Service Communication

↓

API Gateway

↓

Service Discovery

↓

Event-Driven Architecture

↓

Kafka / RabbitMQ

These are the areas I want to explore as the architecture evolves.

Why I'm Building This

ShopEase started as a project to learn Java backend development.

Now it has become a practical way for me to understand how real-world backend systems evolve.

Instead of only learning:

"What is Microservices Architecture?"

I'm trying to understand:

"How would I actually migrate an existing application toward microservices?"

That difference is making the learning experience much more practical.

Final Thoughts

The biggest takeaway from this module is that building a system teaches you things that theory alone cannot fully explain.

Every new architectural decision introduces new challenges, and solving those challenges is becoming part of my learning process.

ShopEase is still evolving, and I am documenting the journey as I continue learning Java, Spring Boot, backend engineering, and system design.

Learn → Build → Solve → Improve. 🚀

🐳 Dockerizing ShopEase: From Local Development to a Containerized Application By Shitanshu Jha

Shitanshu Jha — Thu, 03 Sep 2026 03:24:27 +0000

Hi, I'm Shitanshu Jha, a BCA student and Java Backend Developer focused on building real-world applications using Java, Spring Boot, REST APIs, Spring Security, JPA/Hibernate, and MySQL.

One of the major projects I am currently developing is ShopEase, a full-stack e-commerce application.

ShopEase wasn't built in one go.

I have been developing it step by step and module by module. With every new module, I have faced new problems, debugged issues, understood why they occurred, and then implemented better solutions.

Throughout this journey, I have worked on different parts of an e-commerce system, including authentication, products, cart, wishlist, checkout, orders, validation, exception handling, security, and database integration.

After getting the core application working, I reached another important question:

How can I make ShopEase run consistently without depending entirely on the configuration of my local machine?

This question led me to Docker.

In Module 28, I successfully containerized ShopEase and tested the application with Spring Boot and MySQL running inside Docker containers.

🚀 Why I Added Docker to ShopEase

Before Docker, ShopEase depended heavily on my local development environment.

I needed the correct:

Java environment
MySQL installation
Database configuration
Application configuration
Ports
Credentials and other environment-specific values

My application might work perfectly on my computer, but that doesn't automatically mean it will behave exactly the same way on another machine.

That is the classic:

“It works on my machine.”

problem.

I wanted ShopEase to move beyond that kind of setup.

Instead of thinking only about writing backend code, I wanted to understand how an actual application can be packaged, configured, and run as multiple services.

That's why I decided to containerize it.

🧱 Step 1 — Understanding What Needed to Be Containerized

Before writing Docker configuration, I first looked at the basic ShopEase backend architecture.

It was essentially:

Frontend
│
▼
REST APIs
│
▼
Spring Boot Backend
│
▼
MySQL Database

The backend depends on MySQL.

So simply putting the Spring Boot application inside a container wasn't enough.

I needed two main services:

┌─────────────────────┐
│ Spring Boot Backend │
└──────────┬──────────┘
│
│ Database Connection
▼
┌─────────────────────┐
│ MySQL │
└─────────────────────┘

Both services needed to run independently while still being able to communicate.

That became the foundation of my Docker implementation.

🐳 Step 2 — Creating a Dockerfile for Spring Boot

The next step was creating a Dockerfile for the ShopEase backend.

A Dockerfile defines how Docker should create an image for an application.

The basic flow became:

ShopEase Backend
│
▼
Build Project
│
▼
JAR File
│
▼
Docker Image
│
▼
Docker Container
│
▼
Spring Boot Running

This was an important change in how I thought about the application.

Previously, I was mainly thinking:

Write Code → Run Spring Boot

Now I had to think:

Write Code
↓
Build Application
↓
Package Application
↓
Build Docker Image
↓
Create Container
↓
Run Application

It gave me a better understanding of how backend applications move from development toward deployment.

🗄️ Step 3 — Containerizing MySQL

ShopEase stores application data in MySQL.

So the next task was running MySQL as a separate container.

Now instead of thinking about MySQL only as a database installed on my Windows machine, I could treat it as an independent service.

The architecture started looking like this:

Docker
│
├── ShopEase Backend Container
│ │
│ │
│ ▼
│
└── MySQL Container

But this introduced one of the most important challenges.

⚠️ Challenge 1 — Connecting Spring Boot to MySQL

When both applications are running directly on the same machine, using localhost feels natural.

But containers change this concept.

Inside the Spring Boot container:

localhost

refers to the Spring Boot container itself.

It does not automatically mean the MySQL container.

That was an important concept for me to understand.

I needed the backend container to find and communicate with the database container correctly.

This led directly to the next part of the implementation.

🌐 Step 4 — Docker Networking

To allow the Spring Boot and MySQL containers to communicate, I configured them to work through Docker networking.

Conceptually, the architecture became:

         Docker Network
               │
   ┌───────────┴───────────┐
   │                       │
   ▼                       ▼

┌──────────────┐ ┌──────────────┐
│ Spring Boot │ <────> │ MySQL │
│ Container │ │ Container │
└──────────────┘ └──────────────┘

Instead of treating the database as something running on the host machine, the backend can communicate with the database service inside the Docker environment.

This helped me understand an important Docker concept:

Containers are isolated, but they can communicate through properly configured networks.

⚠️ Challenge 2 — Application Configuration

Getting the containers running was only part of the work.

The Spring Boot application also needed the correct database configuration.

The application needed values such as:

Database Host
Database Port
Database Name
Database Username
Database Password

Hardcoding all of these values directly into the application would make the configuration difficult to manage across different environments.

So I worked with environment variables.

🔐 Step 5 — Using Environment Variables

Environment variables allowed me to separate configuration from application code.

For example, configuration can conceptually be represented as:

DB_HOST
DB_PORT
DB_NAME
DB_USERNAME
DB_PASSWORD

The application can then read these values from its environment.

This means the same application can work with different configurations.

For example:

Development Environment
│
├── Development DB
│
Testing Environment
│
├── Testing DB
│
Production Environment
│
└── Production DB

without requiring the actual application logic to be rewritten.

This also taught me an important backend engineering principle:

Configuration should be separated from application logic whenever possible.

Sensitive credentials should also not be committed directly to a public Git repository.

🧩 Step 6 — Bringing Everything Together with Docker Compose

At this point, ShopEase had more than one container.

I had:

Spring Boot Container
MySQL Container

Starting and managing every service separately would quickly become inconvenient.

That's where Docker Compose became useful.

With Docker Compose, I could describe the services required by ShopEase together.

Conceptually:

docker compose
│
├── Spring Boot Service
│
├── MySQL Service
│
├── Environment Variables
│
└── Networking

Then the complete environment could be managed as one multi-container application.

The startup process became much cleaner:

docker compose up
│
▼
Create / Start Services
│
├───────────────┐
▼ ▼
Spring Boot MySQL
Container Container
│ │
└──── Network ──┘

This was one of the biggest improvements Docker brought to ShopEase.

⚠️ Challenge 3 — Moving from Localhost Thinking to Container Thinking

One of my biggest learnings during this module was that containerized applications require a different way of thinking.

Previously, my environment was mostly:

My Computer
├── Java
├── Spring Boot
└── MySQL

After Docker:

My Computer
│
Docker
│
├── Spring Boot Container
│
└── MySQL Container

The application and database were no longer simply two programs running directly beside each other.

They were independent containers.

That affected:

Hostnames
Networking
Ports
Database configuration
Environment variables
Startup dependencies

Understanding these differences was one of the most valuable parts of this module.

🛠️ My Problem-Solving Approach

I have followed a similar development process throughout ShopEase.

Whenever something doesn't work, I try not to randomly change code until the error disappears.

My approach is generally:

Implement Feature
↓
Run Application
↓
Test Feature
↓
Observe Error
↓
Understand the Cause
↓
Change Configuration / Code
↓
Test Again
↓
Verify Complete Flow

I followed the same approach while implementing Docker.

Containerization introduced new problems because the environment was different from my normal local setup.

I had to understand how the Spring Boot container sees MySQL, how the services communicate, and how configuration should reach the application.

Solving those problems step by step made Docker much easier to understand than simply memorizing Docker commands.

🧪 Step 7 — Testing the Containerized Application

I didn't want to consider the module complete just because the containers started successfully.

The important question was:

Does ShopEase actually work correctly inside this environment?

So I tested the setup to verify that:

✅ Docker image builds correctly
✅ Spring Boot container starts
✅ MySQL container starts
✅ Spring Boot can communicate with MySQL
✅ Docker networking works
✅ Environment variables are passed correctly
✅ Database connectivity works
✅ Backend APIs continue functioning in the containerized environment

After testing the complete flow, I marked:

✅ Module 28 — Docker: Completed & Tested
🏗️ ShopEase Docker Architecture

The final containerized backend architecture can be visualized like this:

                ShopEase
                   │
                   ▼
            Docker Compose
                   │
          Docker Network
                   │
       ┌───────────┴───────────┐
       │                       │
       ▼                       ▼

┌─────────────────────┐ ┌─────────────────┐
│ Spring Boot │ │ MySQL │
│ Container │◄─►│ Container │
│ │ │ │
│ ShopEase Backend │ │ ShopEase Data │
└─────────────────────┘ └─────────────────┘
│
▼
REST APIs
💡 What I Learned From Module 28

Before implementing this module, Docker was mostly another technology on my learning roadmap.

After actually integrating it into ShopEase, I understood why containerization matters.

I gained practical experience with:

Dockerfile — packaging the Spring Boot application.

Docker Images — understanding the blueprint used to create containers.

Docker Containers — running isolated application services.

Docker Compose — managing multiple services together.

Docker Networking — enabling communication between Spring Boot and MySQL.

Environment Variables — separating configuration from application code.

Containerized Databases — running MySQL as an independent service.

But the biggest learning wasn't a Docker command.

It was understanding that:

Building an application is not only about writing code. You also need to think about how that application will be configured, packaged, connected, run, tested, and eventually deployed.

👨‍💻 Building ShopEase Step by Step

ShopEase has been a learning-by-building project for me.

I didn't start by knowing everything required to build the complete application.

Instead, I have been developing it incrementally.

Learn
↓
Implement
↓
Face Problems
↓
Debug
↓
Understand
↓
Improve
↓
Move to Next Module

Every new feature has introduced something new for me to understand.

Some challenges have been related to backend logic, some to databases, some to security and API integration, and now some to infrastructure and containerization.

That process is exactly why I continue developing ShopEase.

The goal isn't just to add a long list of technologies to the project.

The goal is to understand why they are needed and how they work together in a real application.

🚀 What's Next for ShopEase?

Completing Docker doesn't mean ShopEase is finished.

Containerization is another step toward making the project more deployment-oriented.

My upcoming areas of focus include further improving:

Automated testing
CI/CD
Production configuration
Cloud deployment
Monitoring and logging
Backend reliability and optimization

I want to continue evolving ShopEase while learning the engineering practices used beyond local development.

🎯 Conclusion

Module 28 was more than simply adding a Dockerfile to ShopEase.

It changed how I think about running an application.

I moved from running Spring Boot and MySQL as locally configured components to understanding how they can operate as separate but connected containerized services.

During the implementation, I had to understand networking, configuration, environment variables, service communication, and multi-container management.

I faced problems, debugged them step by step, tested the complete setup, and finally got Spring Boot and MySQL running together successfully using Docker Compose.

There is still much more for me to learn and improve, but that's exactly how I am building ShopEase:

One module. One challenge. One solution at a time. 🚀

🐳 Module 28 — Docker

Status: ✅ Completed & Tested

Developed by Shitanshu Jha

Who is Shitanshu Jha?

Shitanshu Jha — Mon, 31 Aug 2026 05:29:21 +0000

Building My Journey as a Java Backend Developer
Shitanshu Jha is a Java Backend Developer building real-world applications with Java, Spring Boot and MySQL.
By Shitanshu Jha · 5 min read
I’m Shitanshu Jha, a BCA student at Guru Gobind Singh Indraprastha University with a growing focus on Java backend development.

My journey started with learning programming fundamentals and gradually moved toward building real applications. Instead of limiting myself to tutorials and small examples, I wanted to understand how the different pieces of a real application actually work together.

That led me to my biggest project so far — ShopEase.

From Learning Java to Building Real Applications

Java became the foundation of my backend development journey.

As I progressed, I moved from Core Java and OOP into technologies such as JDBC, Spring Boot, Spring MVC, Spring Data JPA, Hibernate, REST APIs, Spring Security and MySQL.

The important part wasn't simply learning these technologies individually.

It was learning how they fit together.

A request from a frontend application can travel through a REST controller, reach the service layer, interact with the database through JPA/Hibernate, pass through security mechanisms, and finally return a structured response to the client.

Understanding that flow changed the way I approached backend development.

Building ShopEase

ShopEase is my full-stack e-commerce application built using:

Frontend → HTML, CSS, JavaScript, Fetch API

Backend → Java, Spring Boot, Spring MVC, Spring Data JPA, Hibernate

Security → Spring Security, JWT, BCrypt

Database → MySQL

Payments → Razorpay

The architecture follows a simple but practical flow:

Frontend → Fetch API → Spring Boot REST API → Spring Security + JWT → Service/Repository Layer → MySQL

Building this application helped me move beyond isolated coding exercises and start thinking about application architecture, security, validation, database relationships and business logic.

What I Have Built

ShopEase has grown from a basic product application into a much larger e-commerce system.

The application currently includes:

User signup and login

JWT authentication

BCrypt password hashing

Role-based authorization

Product management

Product search and categories

Product details and specifications

Shitanshu Jha #ShopEase #ShopEaseShitanshuJha #Backend #Software Engineer #SpringBoot #Java

🚀 Building the ShopEase Admin Dashboard — Challenges, Solutions & What I Learned By Shitanshu Jha

Shitanshu Jha — Wed, 26 Aug 2026 06:26:59 +0000

While developing ShopEase, my goal was not just to create a basic e-commerce website. I wanted to build it as a complete application while learning how real-world Java backend systems are designed.

I am currently developing ShopEase as a full-stack e-commerce application using Java, Spring Boot, Spring Data JPA, Hibernate, MySQL, HTML, CSS and JavaScript.

One of the major milestones in this journey was Module 23 — Admin Dashboard.

The dashboard started as a simple admin page, but gradually became a proper management system for products, users, orders, order statuses and inventory.

🛠️ What I Built

The ShopEase Admin Dashboard currently provides:

📊 Dashboard statistics
📦 Product Management
👥 User Management
🛒 Order Management
🔄 Order Status Management
📋 Inventory Management
⚠️ Low Stock Alerts
❌ Out-of-Stock Alerts
🕐 Recent Orders

The dashboard communicates with my Spring Boot backend through REST APIs and retrieves the required data from MySQL using Spring Data JPA.

😵 The Challenges I Faced

Building the dashboard wasn't as straightforward as I initially expected.

The biggest challenges were not creating the HTML cards or buttons. The difficult part was making sure that the frontend, backend, database and business logic were all connected correctly.

Calculating Dashboard Statistics

Initially, the dashboard needed to display information such as:
Total Products
Total Users
Total Orders
Total Revenue

The challenge was deciding where these values should actually come from.

Instead of calculating everything on the frontend, I implemented the logic on the backend.

For example, product and user counts are retrieved using repository operations:

productRepository.count();
userRepository.count();

Similarly, total revenue required a database query that considers only confirmed orders.

This taught me an important lesson:

Dashboard statistics should come from reliable backend data rather than being calculated or trusted on the client side.

Implementing Inventory Alerts

One of the more interesting parts was implementing inventory monitoring.

I wanted the dashboard to show:

Low Stock
Out of Stock

I implemented repository queries such as:

long lowStockProducts =
productRepository.countByStockBetween(1, 10);

long outOfStockProducts =
productRepository.countByStock(0);

This allowed the backend to directly determine the inventory status.

The dashboard could then display something like:

⚠️ Low Stock 13

❌ Out of Stock 1

This was a good example of how a simple UI feature actually requires proper backend and database logic behind it.

Fetching Recent Orders

Another requirement was displaying the latest orders on the Admin Dashboard.

Instead of returning every order and filtering it on the frontend, I created a repository-level query to retrieve recent orders.

The backend then converts the Order entities into a dedicated DTO:

AdminRecentOrderDTO

The response contains information such as:

Order ID
Customer name
Total amount
Order status
Order creation time

This helped me understand why DTOs are useful when exposing database entities through APIs.

Connecting Everything Through a Dashboard Service

I didn't want the controller to contain all the dashboard business logic.

So I created:

AdminDashboardService

The service is responsible for collecting:

Products
Users
Orders
Revenue
Inventory
Recent Orders

and combining them into:

AdminDashboardResponseDTO

This gave me a much cleaner architecture:

Frontend
↓
Controller
↓
Service
↓
Repository
↓
MySQL

Working through this helped me understand the importance of separating responsibilities instead of putting everything inside one class.

🐛 Debugging Was a Major Part of the Work

One thing I learned while developing ShopEase is that writing code is only half the job.

A lot of my time went into debugging.

For example, I encountered issues where repository methods were not recognized correctly, constructors didn't match DTO parameters, and entity fields differed from what the service expected.

There were also situations where the dashboard displayed incorrect inventory numbers.

Instead of randomly changing code, I started checking the complete flow:

Database
↓
Repository
↓
Service
↓
DTO
↓
Controller
↓
API Response
↓
Frontend

That approach made debugging much easier.

📊 Testing the Dashboard

After implementing the features, I tested the dashboard with actual application data.

For example, the backend returned dashboard information similar to:

Total Products: 58
Total Users: 9
Total Orders: 21
Total Revenue: 7798
Low Stock Products: 13
Out of Stock Products: 1

I also tested inventory changes by changing product stock values in the database and verifying that the dashboard updated accordingly.

This helped confirm that the values weren't hardcoded and were actually coming from the database.

🔐 Admin-Specific Functionality

Another important part was making sure that administrative functionality was separated from normal user functionality.

ShopEase already has role-based behavior for:

USER
ADMIN

The Admin Dashboard is therefore intended for administrative operations such as:

Managing products
Managing users
Managing orders
Updating order status
Monitoring inventory

This made me think more seriously about authorization and access control, rather than treating an admin page as just another frontend page.

🚀 From Admin Page to Production-Ready Module

The biggest takeaway from this module is that a dashboard isn't just a collection of cards.

A proper admin dashboard requires:

UI
+
REST APIs
+
Business Logic
+
Database Queries
+
DTOs
+
Validation
+
Authorization
+
Error Handling
+
Testing

That is what made this module much more valuable for me than simply designing an admin interface.

🧠 What I Learned

While working on this module, I learned and practiced:

Spring Boot service-layer architecture
Spring Data JPA repository queries
DTO-based API responses
Database aggregation
Inventory management logic
Order management
Role-based functionality
Debugging backend/frontend integration
API testing
Separating business logic from controllers
Designing features around actual application data

More importantly, I learned that production-ready development is mostly about handling the problems that appear between different parts of the system.

👨‍💻 About Me

I'm Shitanshu Jha, a BCA student and developer currently building ShopEase as a hands-on project to strengthen my skills in Java backend and full-stack development.

Instead of only learning technologies theoretically, I'm trying to understand them by building a complete application step by step.

With ShopEase, I'm working with:

Java
Spring Boot
Spring MVC
Spring Data JPA
Hibernate
MySQL
REST APIs
JWT
Spring Security
HTML
CSS
JavaScript
Git & GitHub
Postman

ShopEase is still an ongoing project, and I'm continuing to improve it module by module.

The objective isn't simply to finish another college project.

I'm using ShopEase to understand how real software is designed, debugged, tested and gradually made production-ready.

🚀 What's Next?

With the Admin Dashboard completed, ShopEase has moved into Phase 6 — Production Ready.

The next focus is improving the application's production-level capabilities, including:

Logging
Better error tracking
Reliability
Security improvements
Performance
Deployment considerations

There is still a lot to build, but every module is teaching me something that a tutorial alone couldn't.

ShopEase is not finished yet — and that's the point.

Java

Spring Boot

Backend Development

Full Stack Development

Web Development

I Integrated Razorpay Payments into My Java Spring Boot E-Commerce Project — Challenges, Bugs, and What I Learned

Shitanshu Jha — Sun, 23 Aug 2026 12:13:24 +0000

💳 Integrating Razorpay Payment Gateway into My Java Spring Boot E-Commerce Project

Building an e-commerce application is not just about displaying products and adding them to a cart.

At some point, the application needs to handle one of the most important parts of the entire flow:

Payments.

While working on my ShopEase, a full-stack e-commerce application built with Java Spring Boot, MySQL, JavaScript and JWT authentication, I recently implemented Razorpay Test Mode payments.

The implementation looked straightforward at first:
Checkout
↓
Create Order
↓
Create Razorpay Order
↓
Open Razorpay Checkout
↓
Verify Payment
↓
Confirm Order
But in practice, there were several problems that I had to debug and solve.

This post documents what I actually implemented, the problems I faced, and what I learned from them.

🛒 About ShopEase

ShopEase is my full-stack e-commerce project.

Tech Stack

Frontend

HTML
CSS
JavaScript
Fetch API
LocalStorage

Backend

Java
Spring Boot
Spring MVC
Spring Data JPA
Hibernate
Spring Security
JWT
BCrypt

Database

MySQL

Payment Gateway

Razorpay

Tools

Eclipse
Postman
XAMPP
Git
GitHub

Before implementing payments, I already had:

User authentication
JWT authorization
Product system
Shopping cart
Wishlist
Checkout
Order creation
Order history

So the next logical step was integrating payments.

🎯 What I Wanted to Build

I didn't want Razorpay to simply open a payment popup.

I wanted a complete payment lifecycle.

The final architecture became:
User
↓
Cart
↓
Checkout
↓
POST /orders
↓
ShopEase Order Created
↓
POST /payments/create
↓
Razorpay Order Created
↓
Razorpay Checkout
↓
Payment
├── SUCCESS
│ ↓
│ Verify Signature
│ ↓
│ Payment = SUCCESS
│ ↓
│ Order = CONFIRMED
│ ↓
│ Cart Cleared
│
└── FAILURE
↓
Payment = FAILED
↓
Order = PENDING
↓
Cart Preserved
This distinction between ShopEase Order and Razorpay Order was one of the most important concepts I learned during the implementation.

🧩 Step 1 — Creating a Razorpay Order

I created a backend endpoint:
POST /payments/create
The frontend sends:

orderId
amount

The backend first finds the ShopEase order.

Then I validate that the payment amount matches the actual order amount.

if (!order.getTotalAmount().equals(amount)) {
throw new RuntimeException(
"Payment amount does not match order amount"
);
}

I then convert the amount into paise:

int amountInPaise =
(int) Math.round(amount * 100);

and create the Razorpay order.

The Razorpay order ID is then stored in my Payment entity.

This gives me a relationship like:

ShopEase Order
↓
Payment
↓
Razorpay Order ID
🔐 Step 2 — Payment Verification

One of the most important parts of the integration was payment verification.

After successful payment, Razorpay provides:

razorpay_order_id
razorpay_payment_id
razorpay_signature

I send these values to:

POST /payments/verify

The backend constructs the signature payload:

String payload =
razorpayOrderId
+ "|"
+ razorpayPaymentId;

Then I verify the signature using the Razorpay secret:

Utils.verifySignature(
payload,
razorpaySignature,
System.getenv("RAZORPAY_KEY_SECRET")
);

I deliberately kept the secret on the backend instead of exposing it in JavaScript.

🐛 Challenge 1 — Order ID Was Missing

This was one of the first real bugs I encountered.

The frontend initially expected the order response to directly contain the order ID.

But my backend response was wrapped inside my standard:

ApiResponse

The actual response structure was effectively:

{
"success": true,
"message": "Order placed successfully",
"data": {
"orderId": 14,
"totalAmount": 4299
}
}

My frontend initially wasn't extracting the nested data correctly.

This resulted in:

Order created but Order ID was not received.

I debugged it by printing the raw response:

console.log(
"RAW ORDER RESPONSE:",
JSON.stringify(order, null, 2)
);

The response showed me that I was reading the wrong level of the JSON structure.

I fixed the API layer so that placeOrder() returns:

return {
orderId: order.orderId,
totalAmount: order.totalAmount
};

This was a good reminder that frontend/backend integration bugs are often response-contract bugs, not business-logic bugs.

🐛 Challenge 2 — Razorpay Was Not Opening Reliably

Another confusing problem was that Razorpay sometimes didn't open when I clicked Place Order from the cart flow.

But when I manually opened Checkout.html, it worked.

I initially suspected Razorpay itself.

The actual problem was in my application flow and state handling around the cart/checkout page.

I traced the complete flow instead of assuming the payment gateway was broken:

Cart
↓
Checkout
↓
Create Order
↓
Create Razorpay Order
↓
Open Razorpay

This debugging process helped me separate:

application bugs

from

payment gateway bugs.

That distinction saved a lot of time.

🐛 Challenge 3 — Payment Failed But Database Still Had CREATED

This was a more important backend problem.

When a Razorpay payment failed, I initially had a record like:

Payment
Status = CREATED

even though the user had already failed the payment.

That meant my database wasn't representing the actual payment state.

I implemented a failure endpoint:

POST /payments/fail

and added logic to update the payment:

payment.setStatus(
PaymentStatus.FAILED
);

paymentRepository.save(payment);

The frontend listens for Razorpay's failure event:

razorpay.on(
"payment.failed",
async function(response) {
...
}
);

and records the failure on the backend.

After that, my database correctly reflected:

Payment → FAILED
🐛 Challenge 4 — Failed Payment Was Clearing My Cart

This was probably the most important business-logic issue I encountered.

Initially, the order creation flow deleted cart items immediately after creating the order.

That produced this problem:

Cart
↓
Create Order
↓
Cart deleted ❌
↓
Payment
↓
Payment FAILED

Now the customer had paid nothing, but their cart was already empty.

That's bad e-commerce behavior.

✅ The Solution — Clear Cart Only After Successful Payment

I changed the flow so that creating an order does not immediately delete the cart.

Instead:

Order Created
↓
Payment Created
↓
Razorpay Payment

Only after successful payment verification:

Payment SUCCESS
↓
Order CONFIRMED
↓
Cart Cleared

The backend finds the user's cart:

Cart cart =
cartRepository
.findByUser(order.getUser())
.orElse(null);

Then retrieves its items:

List cartItems =
cartItemRepository
.findByCart(cart);

and deletes them only after successful payment.

This gives the correct behavior:

Successful payment
Payment = SUCCESS
Order = CONFIRMED
Cart = EMPTY
Failed payment
Payment = FAILED
Order = PENDING
Cart = PRESERVED
🧠 Challenge 5 — Java Method/Brace Error

While modifying PaymentService, I also introduced a simple but annoying Java structure error.

I accidentally placed:

markPaymentAsFailed()

inside:

verifyPayment()

because a closing brace was missing.

The compiler then highlighted:

return true;

which initially made it look like return true itself was the problem.

The actual issue was the method structure.

The correct structure is:

verifyPayment() {
...
return true;
}

markPaymentAsFailed() {
...
}

This was a small bug, but it reinforced an important debugging lesson:

When Java highlights a perfectly valid line, don't automatically assume that line is the real problem. Check the surrounding structure first.

🔄 Final Payment Flow

After fixing these issues, the complete flow became:

             SHOP EASE
                 │
               Cart
                 │
             Checkout
                 │
          Create Order
                 │
          MySQL Order
                 │
      Create Razorpay Order
                 │
         Razorpay Checkout
             /       \
            /         \
       SUCCESS       FAILURE
          │              │
   Verify Signature      │
          │              │
    Payment SUCCESS  Payment FAILED
          │              │
   Order CONFIRMED   Order PENDING
          │              │
     Clear Cart     Keep Cart

🧪 Testing

I tested both important scenarios.

Successful Payment

Result:

Order ID: 20
Status: CONFIRMED
Total: ₹3499
Payment: SUCCESS
Cart: Cleared
Failed Payment

Result:

Payment: FAILED
Order: PENDING
Cart: Preserved

This was important because testing only successful payments would have hidden the cart-loss bug.

🔒 Security Considerations

I also made sure that sensitive payment information wasn't trusted blindly from the frontend.

The backend:

Validates the order amount
Creates the Razorpay order
Stores the Razorpay order ID
Verifies the Razorpay signature
Keeps the Razorpay secret on the backend
Updates payment status on the backend
Updates order status only after successful verification

The frontend is responsible for initiating the checkout experience, but the backend is responsible for trusting and recording the payment result.

📚 What I Learned

The biggest lesson wasn't actually how to call the Razorpay API.

It was understanding that payment integration is a state-management problem.

A payment can move through states like:

CREATED
↓
SUCCESS

or:

CREATED
↓
FAILED

And the order has its own state:

PENDING
↓
CONFIRMED

These states need to remain consistent.

I also learned:

Never clear a cart before payment succeeds.
Always verify payment on the backend.
Don't expose payment secrets in frontend code.
Debug the complete frontend → API → service → database flow.
API response structure matters as much as business logic.
Always test failure scenarios, not just the happy path.
Payment integration is tightly connected to order and cart state.
🚀 What's Next?

Razorpay completes another major part of ShopEase.

The next areas I want to work on are:

Admin Dashboard
User Management
Inventory Management
Automated Testing
Pagination
Sorting
Advanced Search
Docker
CI/CD
Deployment

Eventually, I want to take ShopEase from a learning project toward a more production-oriented architecture.

🎯 Final Thoughts

Implementing Razorpay wasn't just about adding a payment popup.

The real challenge was making sure that:

Payment
↕
Order
↕
Cart

all remain consistent.

The bugs I encountered—missing order IDs, incorrect response handling, failed payment state, cart deletion and Java method structure issues—were actually more valuable than simply getting the first successful payment.

That's what made this implementation useful as a development experience.

ShopEase now has a complete tested payment flow using Razorpay Test Mode, with backend verification, payment status tracking, order confirmation, failure handling and correct cart behavior.
ShopEase -Shitanshu Jha

java #springboot #razorpay #ecommerce #webdev

Building ShopEase: My Journey From a Basic E-Commerce App to a Spring Boot Backend

Shitanshu Jha — Sat, 22 Aug 2026 02:33:38 +0000

Building ShopEase: My Journey From a Basic E-Commerce App to a Spring Boot Backend

By Shitanshu Jha

**👋 Hi, I'm Shitanshu Jha

I'm a BCA student and Java Developer focused on backend development and building real-world applications with Java, Spring Boot, REST APIs, MySQL, and Spring Security.**

I'm currently pursuing my Bachelor of Computer Applications at Guru Gobind Singh Indraprastha University (GGSIPU). While learning software development, I wanted to move beyond small practice programs and understand how a complete application is actually designed, connected, secured, tested, and developed over time.

That's what led me to build ShopEase.

ShopEase is a full-stack e-commerce application that I'm developing module by module, starting from basic product management and gradually adding authentication, authorization, cart management, wishlist, checkout, orders, and payment integration. The project currently has a Java/Spring Boot backend, JavaScript frontend, MySQL database, JWT authentication, role-based authorization, and several integrated modules.**

How I built and evolved a full-stack e-commerce application using Java, Spring Boot, MySQL, JavaScript, JWT authentication, and REST APIs.
When I started building ShopEase, my goal wasn't to create a perfect e-commerce application from day one.

I wanted to understand what actually happens behind a real application — how the frontend communicates with a backend, how data is stored, how authentication works, how users are authorized, and how different features come together into one system.

ShopEase started as an e-commerce project and gradually evolved into a much larger full-stack application.

Today, it has a Java + Spring Boot backend, a JavaScript frontend, MySQL database integration, JWT authentication, role-based authorization, persistent cart and wishlist functionality, checkout and order management, validation, DTOs, and centralized exception handling.
🛠️ Tech Stack
Frontend
HTML
CSS
JavaScript
Fetch API
LocalStorage
Backend
Java
Spring Boot
Spring MVC
Spring Data JPA
Hibernate
Spring Security
JWT
BCrypt
Jakarta Validation
Database
MySQL
Tools
Eclipse
Postman
XAMPP
Git
GitHub
🏗️ The Architecture

The basic architecture of ShopEase looks like this:

                ShopEase
                   │
      ┌────────────┴────────────┐
      │                         │
  FRONTEND                   BACKEND
      │                         │
HTML / CSS / JS            Spring Boot
      │                         │
  Fetch API               Spring MVC
      │                         │
   api.js               Spring Security
      │                         │
      └────── REST API ─────────┘
                   │
                  JWT
                   │
                 MySQL

The frontend communicates with the Spring Boot backend through REST APIs, while authentication is handled using JWT.

📦 1. Building the Product System

The product module was one of the first major parts of ShopEase.

On the frontend, I implemented product cards containing information such as:

Product image
Name
Brand
Description
Price
Old price
Discount
Rating
Stock status
Add to cart
View details

On the backend, the product system includes:

Product Entity
Repository
Service
Controller
MySQL integration
JPA/Hibernate
CRUD operations
DTOs
Validation
Exception handling

The main REST APIs are:

GET /products
GET /products/{id}
POST /products
PUT /products/{id}
DELETE /products/{id}

The data flows from the frontend through the Fetch API to the controller, service, repository and finally MySQL before returning a JSON response to the frontend.

🔐 2. Authentication with Spring Security and JWT

This was one of the more important parts of the project.

I implemented:

User registration
Login
BCrypt password encoding
JWT generation
JWT validation
JWT authentication filter
Protected APIs
Role-based authorization

The login flow looks like:

For protected requests, the frontend automatically sends:

Authorization: Bearer

The backend then validates the JWT through the authentication filter and Spring Security context.

👥 3. Role-Based Authorization

I didn't want authentication to simply mean “the user is logged in.”

Different users should have different permissions.

ShopEase currently has USER and ADMIN roles.

For example:

USER
↓
Protected API
↓
Unauthorized operation
↓
403 Forbidden

while:

ADMIN
↓
Protected Admin API
↓
Allowed

This is used for operations such as product and specification management.

🛒 4. Building a Persistent Shopping Cart

The cart was where the frontend and backend really started behaving like one application.

The backend contains:

User
↓
Cart
↓
CartItem
↓
Product

The cart supports:

Add product
View cart
Update quantity
Remove item
Stock validation
Quantity validation
Subtotal
Total
Total item count

The APIs are:

POST /cart
GET /cart
PUT /cart/{itemId}
DELETE /cart/{itemId}

The important part was making the cart persistent.

If a user adds a product, logs out, and later logs in again, the cart is restored from the database instead of being lost.

🤍 5. Adding Wishlist Functionality

After the cart, I implemented a user-specific persistent wishlist.

The backend provides:

POST /wishlist/{productId}
GET /wishlist
DELETE /wishlist/{itemId}

The frontend includes:

Wishlist button
Wishlist count
Wishlist drawer
Product cards
Add/remove functionality
Wishlist state synchronization
Empty wishlist UI

I also added duplicate-product handling and ownership validation.

The wishlist module is currently fully integrated and tested.

🧾 6. DTOs, Validation and Exception Handling

As the project became bigger, I realized that directly exposing entities through APIs wasn't a good approach.

So I introduced DTOs such as:

ProductRequestDTO
ProductResponseDTO

UserRequestDTO
UserResponseDTO

LoginRequestDTO
LoginResponseDTO

AddToCartRequestDTO
UpdateCartItemDTO

CartItemResponseDTO
CartResponseDTO

The purpose was to separate the API layer from the entity layer and control exactly what data enters and leaves the application.

I also implemented Jakarta Validation with annotations such as:

@notblank
@NotNull
@positive
@min
@max

and created a centralized GlobalExceptionHandler for validation, authentication, product, stock and cart-related errors.

🧾 7. Checkout and Orders

The project has now moved beyond just shopping-cart functionality.

Checkout and order management are implemented and tested.

The current flow is:

USER
↓
Cart
↓
Checkout
↓
POST /orders
↓
Order Success
↓
Order Details
↓
My Orders
↓
Order History

The backend supports:

POST /orders
GET /orders
GET /orders/{id}

It also handles user-specific order history and order-status transitions.

🚧 What's Next?

The next major target is payment integration.

I'm currently planning the Razorpay integration around:

Payment order creation
Payment verification
Payment status handling
Order-payment integration
Successful payment handling
Failed payment handling
Payment security
Payment testing

The frontend will also have payment initiation and success/failure handling.

After that, the longer-term roadmap includes production hardening, automated testing, Docker, CI/CD, deployment, and eventually more advanced architecture such as microservices and event-driven communication.

🧠 What I'm Learning From ShopEase

The biggest thing I've learned from this project is that building a real application is very different from writing isolated code.

A feature isn't finished when the Java class compiles.

It has to go through a complete workflow:

Backend Development
↓
API Testing
↓
Frontend Development
↓
API Integration
↓
Full Feature Testing
↓
Bug Fixing
↓
Git Commit
↓
Git Push

That process has become an important part of how I'm developing ShopEase.

🚀 What's Next for ShopEase?

The final goal is to take ShopEase from a learning project toward a production-oriented full-stack e-commerce application.

The long-term architecture is planned around:

Frontend
↓
Spring Boot Backend
↓
MySQL
↓
JWT Authentication
↓
Role-Based Authorization
↓
Cart + Wishlist
↓
Checkout
↓
Orders
↓
Payment
↓
Admin Dashboard
↓
Inventory
↓
Testing
↓
Docker
↓
CI/CD
↓
Cloud Deployment

The project is being developed module by module, with backend development, frontend integration, testing and Git commits forming the development workflow

ShopEase is still a work in progress.

I'm not trying to rush toward calling it “production-ready.” There are still important areas left to build, including payment integration, automated testing, Docker, CI/CD, deployment and production hardening.

For me, that's actually the point of the project.

I'm using ShopEase to understand how a real full-stack application grows from individual features into a complete system — one module at a time.

GitHub: github.com/Shitanshu686
Portfolio: shitanshu686.github.io/ShitanshuJhaaaa/
LinkedIn: linkedin.com/in/shitanshu-jha-738012342/