DEV Community: Shitanshu Jha

WalkQuest AI: Turning Screen Time into Outdoor Adventures 🌿

Shitanshu Jha — Sun, 11 Oct 2026 08:04:23 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass

What if AI didn't try to keep you on your screen, but actually encouraged you to step away from it?

That question inspired WalkQuest AI, a small project built around a simple idea: turn a user's available time, interests, and mood into a short outdoor quest.

🌱 What is WalkQuest?

WalkQuest AI helps people take small breaks from screens and reconnect with the world around them. Instead of scrolling through another feed, users can generate a simple outdoor activity plan for walking, gardening, mindfulness, nature observation, or exploration.

The goal isn't to replace the outdoors with another app. It's to make the time spent using the app short, useful, and purposeful.

✨ Features

AI-generated quests: Describe what you feel like doing and how much time you have.
Multiple activity categories: Walking, gardening, mindfulness, nature, exploration, and observation.
Three-step quests: Break an outdoor break into three manageable activities.
Phone Pocket: A reminder to put the phone away and focus on the real world.
Quest timer and completion flow: Start an outdoor session, return, and reflect on the experience.
Progress tracking: Keep track of completed quests and related activity stats.

🧠 How I built it

WalkQuest uses Gemma 3 1B through Ollama for local AI inference. The application is built with Java and Spring Boot, with a browser-based frontend.

The backend sends a structured prompt to the local model and processes the generated quest into a title, duration, category, difficulty, and three activities.

I also worked on fallback behavior so that Hinglish requests can receive predictable, understandable activities when generated language quality is unreliable.

Tech stack

Java and Spring Boot
Gemma 3 1B
Ollama for local inference
HTML, CSS, and JavaScript
Maven

🎬 Demo

Watch the WalkQuest AI demo: Upload/embed the attached
Demo Video: https://youtu.be/PcGwOobycqA video here.

The demo shows the quest-generation flow and the app's outdoor-session experience.

🌍 Why open innovation matters

An app designed to help people spend less time on screens should not depend entirely on a remote AI service.

Using an open-weight model with local inference gives developers more control over how AI is run, how prompts are designed, and how the model fits into the application. Once the model has been downloaded, inference can run locally through Ollama, without sending each generation request to a hosted model API.

It also makes experimentation more accessible: developers can inspect the code, change the prompts, improve fallback behavior, and explore other compatible models instead of being locked into one closed service.

Local inference does not automatically make every part of an application offline, but it gives this project a foundation for more private and flexible AI experiences.

🛠️ Run it locally

Repository: https://github.com/Shitanshu686/walkquest

Requirements:

Java 17 or later
Git
Ollama installed
The gemma3:1b model downloaded

Clone the repository:

git clone https://github.com/Shitanshu686/walkquest.git
cd walkquest

Download the model and start Ollama:

ollama pull gemma3:1b
ollama serve

In another terminal, launch the application using the repository's run-walkquest.bat script on Windows, or use the Maven wrapper:

./mvnw spring-boot:run

Open the local address and port printed by the application.

🚀 What's next?

I'd like to improve multilingual generation quality, expand the available quest types, and make outdoor progress tracking more useful without adding unnecessary screen time.

WalkQuest is an experiment in building AI that helps people do something beyond interacting with AI itself.

Build with open AI. Step outside. Touch grass. 🌿

Prize categories: Best Use of Gemma

Tags: #devchallenge #hf26challenge #opensource #ai #java

🎬 WalkQuest AI — Live Demo

Watch the demo to see WalkQuest AI in action, including outdoor quest generation and the screen-free activity flow.
Demo Video: https://youtu.be/PcGwOobycqA

▶️ Watch WalkQuest AI Demo on YouTube

The demo showcases how WalkQuest turns a simple request into an outdoor activity experience.

Source Code: https://github.com/Shitanshu686/walkquest

Handling Concurrent Requests and Duplicate Checkouts in Spring Boot

Shitanshu Jha — Sat, 10 Oct 2026 05:52:34 +0000

While building ShopEase, my e-commerce backend project, I reached a stage where implementing CRUD endpoints was no longer enough.

I needed to think about what happens when multiple customers try to update the same inventory or submit the same checkout request simultaneously.

That led me to work on a new backend milestone focused on high-concurrency handling and idempotency protection.

Here are the key implementations and what I learned from them.

Atomic SQL Updates for Inventory

Consider a product with five units in stock. Multiple purchase requests may arrive at almost the same time.

Reading the stock in Java, subtracting a quantity, and saving the entity can introduce race conditions if competing requests read the same initial value.

I added a conditional atomic SQL update:

UPDATE products
SET stock = stock - :qty
WHERE id = :id
AND stock >= :qty;

The database performs the stock check and deduction as one statement.

The affected-row count indicates whether the update succeeded, allowing the application to handle insufficient stock.

This approach reduces unnecessary application-side read-modify-write operations. It does not mean the database performs the operation without any internal locking.

Pessimistic vs. Optimistic Locking

I worked with both locking strategies in DatabaseConcurrencyService.

Pessimistic locking

Pessimistic locking requests a write lock on a database record while the transaction performs its work.

With JPA, this can be implemented using LockModeType.PESSIMISTIC_WRITE.

It is useful when conflicting updates are likely, although excessive lock contention can reduce throughput.

Optimistic locking

Optimistic locking detects conflicting changes rather than preventing every competing transaction from proceeding.

I added a JPA version field:

@version
private Long version;

Hibernate uses the version to detect stale updates. A conflicting update can fail and require the application to handle or retry the operation.

My takeaway: Both strategies are useful, but they address concurrency differently. The choice depends on the workload and conflict rate.

Spring Transaction Proxies and Executor Threads

One important detail I worked on was self-proxy injection.

Spring typically applies @Transactional behavior through a proxy. A direct call such as this.someTransactionalMethod() can bypass the proxy and therefore bypass the expected transaction interception.

Calling the method through the injected Spring proxy allows the transaction interceptor to run.

There is another important detail: an executor thread does not automatically inherit the caller's transaction. A transactional method invoked through the proxy needs to establish its own transaction as required.

This was a useful reminder that asynchronous execution and transaction boundaries must be considered together.

Idempotency Protection for Checkout

Checkout requests can be repeated because of network issues, client retries, or accidental double-clicks.

I implemented IdempotencyKey validation to detect duplicate checkout requests and return 409 Conflict for duplicates.

The basic flow is:

Receive a checkout request with an idempotency key.

Validate whether the key has already been used.

Process a new request.

Reject a duplicate request.

For reliable production behavior, checking and recording the key must be atomic. A database uniqueness constraint is one common way to enforce this. The design also needs clear rules for retries, failed requests, and payment side effects.

The goal is to avoid processing the same logical checkout operation more than once.

JPA Versioning and Application Configuration

I added the version column required for optimistic locking and resolved a Spring bean collision.

These changes help detect stale database updates and allow the application context to initialize with the intended bean configuration.

Key Takeaways

This milestone helped me understand that reliable backend development involves more than writing endpoints.

Use atomic database operations for conditional inventory updates.

Choose pessimistic or optimistic locking according to the workload.

Understand how Spring proxies affect transaction management.

Design executor-thread work with explicit transaction boundaries.

Protect checkout side effects against duplicate requests.

Use JPA versioning to detect conflicting updates.

Final Thoughts

Working on ShopEase is helping me connect Java, Spring Boot, database concurrency, and real e-commerce requirements.

This milestone is a step toward making inventory management and checkout processing more reliable under concurrent load.

I'm continuing to build and improve ShopEase one backend milestone at a time.

Tech stack: Java, Spring Boot, Spring Data JPA, Hibernate, MySQL

Java #SpringBoot #BackendDevelopment #MySQL

ShopEase — Module 32: Solving Inventory Overselling with Concurrency Control

Shitanshu Jha — Mon, 05 Oct 2026 04:21:33 +0000

In an e-commerce application, multiple users can try to purchase the same product at exactly the same time.
This creates a common backend problem: Race Conditions.
The Problem
Suppose a product has only 10 items in stock.
Now imagine 50 users place an order simultaneously.
Without proper concurrency handling, multiple threads may read the same stock value before any of them updates it:
Stock = 10
→ Thread 1 reads 10
→ Thread 2 reads 10
→ Thread 3 reads 10
→ ...
→ Multiple threads try to purchase
The result can be incorrect stock updates and overselling, where the system accepts more orders than the available inventory.
This is a serious problem for an e-commerce backend.
The Solution
In ShopEase, I implemented Concurrency, Multithreading & Database Locking to handle these situations safely.
The inventory update process now uses:

Multithreading for concurrent request testing
Optimistic Locking using @version
Pessimistic Locking using @lock(LockModeType.PESSIMISTIC_WRITE)
Database row locking with FOR UPDATE
Atomic stock deduction
Proper transaction handling With pessimistic locking, when one transaction is updating a product's stock, other transactions have to wait instead of modifying the same row simultaneously. 50-Thread Stress Testing To verify the implementation, I performed concurrent testing with 50 threads trying to purchase the same product. The test focused on: 50 concurrent requests → Stock validation → Locking → Atomic deduction → Order result The important result was: No negative stock. No overselling. Concurrent requests handled safely. What This Module Solved The main problem solved in this module was protecting inventory from race conditions during simultaneous purchases. This makes the ShopEase backend more reliable when multiple users interact with the same product at the same time. Key Takeaway Concurrency isn't just about running multiple threads. In a real e-commerce system, it is about making sure that multiple operations happening simultaneously still produce a correct and consistent result. Tech Stack: Java • Spring Boot • Spring Data JPA • Hibernate • MariaDB • Multithreading • Optimistic Locking • Pessimistic Locking #Java #SpringBoot #Concurrency #Multithreading #DatabaseLocking #Hibernate #MariaDB #BackendDevelopment #ShopEase

MomTask AI: A Hindi/Hinglish Voice Reminder Assistant I Built for My Mother

Shitanshu Jha — Mon, 05 Oct 2026 03:29:36 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built MomTask AI, a simple Hindi/Hinglish AI reminder assistant designed around a real problem my mother could face: turning everyday spoken reminders into organized tasks.

For example:

"Kal subah doodh lana hai"

MomTask understands this as:

Task: Bring milk
Date: Tomorrow
Time: Morning
Reminder: 08:00 AM

The idea is simple: instead of opening a complicated task manager and typing everything manually, a user can speak or type naturally.

Features

Hindi/Hinglish task understanding
Voice input through the microphone
Add, complete and delete tasks
Browser reminder notifications
Custom reminder time
Local H2 database
Local AI using Ollama + Qwen3 1.7B
One-click Windows launcher

Demo

MomTask currently runs locally on Windows.

The project includes a MomTask.bat launcher that starts the required services and opens the application.

After starting it, the app is available at:


text
http://localhost:8080
The microphone button allows Hindi voice input directly from the browser.
Code
GitHub repository:
https://github.com/Shitanshu686/MomTask
The complete source code, README, launcher and Spring Boot project are available in the repository.
How I Built It
The backend is built with Java 17 and Spring Boot.
The basic flow is:
User
  ↓
MomTask Web UI
  ↓
Spring Boot Backend
  ↓
Ollama
  ↓
Qwen3 1.7B
  ↓
Structured Task
  ↓
H2 Database

The AI receives the user's Hindi/Hinglish reminder and extracts:
- task
- date hint
- time
For common Hindi words such as aaj, kal, subah, dopahar, shaam and raat, the application also applies deterministic normalization so the final task data remains predictable.
I also added browser notifications and custom reminder times so the application is useful beyond simply creating a task.
The AI runs locally through Ollama, so the application does not require a cloud AI API key.
Why Does Open Innovation Matter?
Open innovation matters because it makes it possible to experiment, build and adapt technology around real people and real problems.
For MomTask, using a locally running open-weight AI model made the project more personal and privacy-friendly. The AI processing can happen on the user's own computer instead of sending everyday reminders to a remote service.
It also gave me the freedom to experiment with prompts, application logic and the overall user experience while keeping the project simple enough to understand and modify.
What I Learned
The biggest lesson from this project was that an AI application does not need to be complicated to be useful.
The interesting part was not just connecting an AI model. It was combining AI with normal application logic, voice input, reminders, persistence and a simple interface designed around a specific person.
I also learned that local AI performance depends heavily on the available hardware, so designing a lightweight workflow is important.
Built For
I built MomTask AI for my mother as part of the Hacktoberfest 2026 DEV Launch Weekend Build for a Friend challenge.
The goal was to build something useful for a real person rather than making another generic AI demo.
#devchallenge #weekendchallenge #hf26challenge

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.

DEV Community: Shitanshu Jha

WalkQuest AI: Turning Screen Time into Outdoor Adventures 🌿

🌱 What is WalkQuest?

✨ Features

🧠 How I built it

🎬 Demo

🌍 Why open innovation matters

🛠️ Run it locally

🚀 What's next?

🎬 WalkQuest AI — Live Demo

Handling Concurrent Requests and Duplicate Checkouts in Spring Boot

Java #SpringBoot #BackendDevelopment #MySQL

ShopEase — Module 32: Solving Inventory Overselling with Concurrency Control

MomTask AI: A Hindi/Hinglish Voice Reminder Assistant I Built for My Mother

What I Built

Features

Demo

ShopEase — Module 32: Concurrency, Multithreading & Database Locking

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

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

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

Module 30.11 — Microservices Integration & Testing | ShopEase

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

From Monolith to Microservices: My ShopEase Backend Journey

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

Who is Shitanshu Jha?

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

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

Java

Spring Boot

Backend Development

Full Stack Development

Web Development