Building a backend application is not just about writing APIs and connecting databases. As an application grows, important questions start appearing:

How can the system handle increasing traffic?

What happens when a service becomes unavailable?

How should databases and caches be used?

How do different services communicate?

How can we maintain data consistency?

In Module 41 — System Design, I focused on understanding these architectural decisions through the ShopEase e-commerce backend.

1. Scalability: Handling Application Growth

Scalability is the ability of a system to handle increasing workloads.

Two common approaches are:

Vertical Scaling: Increasing the resources of an existing server, such as CPU and RAM.

Horizontal Scaling: Adding more instances of an application to distribute incoming requests.

Understanding the difference helps in choosing an appropriate scaling strategy as application traffic grows.

2. Availability and Reliability

Availability refers to whether a system is accessible when users need it.

Reliability focuses on whether the system continues to perform its intended operations correctly.

These are important considerations for e-commerce applications, where failures in order processing, payments, or inventory operations can affect users.

3. CAP Theorem and Data Consistency

The CAP theorem describes the trade-offs between Consistency, Availability, and Partition Tolerance in distributed data systems.

I explored how these concepts influence architectural decisions, particularly when multiple services and databases are involved.

Data consistency is especially important in operations such as order placement, inventory updates, and payment processing.

4. Load Balancing and Database Scaling

Load balancing distributes incoming requests across multiple application instances.

Database scaling focuses on handling growing data volumes and query workloads.

These concepts help explain how backend systems can manage increasing traffic without placing all the workload on a single application instance or database.

5. Caching Architecture

Caching helps reduce repeated database queries by temporarily storing frequently accessed data.

In ShopEase, Redis is part of the backend architecture. Understanding caching at the system-design level helped connect cache usage with response time, database workload, and cache consistency.

6. Message Queues and Microservices Architecture

Microservices divide an application into smaller services with specific responsibilities.

Message queues support asynchronous communication between services.

In ShopEase, Apache Kafka is used as part of the event-driven architecture. This provides a practical context for understanding asynchronous communication and service coordination.

7. Fault Tolerance and High Availability

Fault tolerance focuses on how a system handles component failures.

High availability aims to minimize service interruptions.

I studied these concepts to understand the architectural approaches used to reduce the impact of failures in distributed applications.

Key Learnings

Module 41 helped connect backend development with broader system-design concepts:

Scalability: Vertical and horizontal scaling.

Availability and reliability.

CAP theorem and distributed data consistency.

Load balancing and database scaling.

Redis-based caching architecture.

Kafka and asynchronous messaging.

Microservices communication.

Fault tolerance and high availability.

Conclusion

System design is about understanding the decisions behind an application's architecture, not simply adding more technologies.

Through ShopEase, I am connecting concepts such as caching, microservices, databases, and messaging with the architectural challenges that appear as an application grows.

Module 41 marks an important step in understanding not just how to build backend systems, but also how to think about their architecture.

Project: ShopEase — Full-Stack E-Commerce Application

GitHub Repositories:

Backend: https://github.com/Shitanshu686/shopping-app-backend

Frontend: https://github.com/Shitanshu686/shopping-app

#Java #SpringBoot #SystemDesign #Microservices #BackendDevelopment

When a client makes an HTTP request to an e-commerce platform, tracing the request lifecycle via a unique Correlation ID across REST and gRPC endpoints is relatively straightforward using thread-local storage like SLF4J's MDC (Mapped Diagnostic Context). However, the moment that request triggers a state change—such as placing an order—and pushes an event into an asynchronous message broker like Apache Kafka, that execution jumps across thread boundaries.

The background consumer thread picking up the message from the queue has no native awareness of the incoming HTTP thread's context. Without explicit propagation, your correlation ID is lost, turning distributed log aggregation and debugging in production into a guessing game.

In this article, we look at how we solved this architectural hurdle in ShopEase—a production-grade Spring Boot e-commerce backend—by engineering a seamless, non-intrusive Distributed Tracing and Correlation ID Propagation Pipeline across Kafka thread boundaries.

The Problem: Context Loss Across Asynchronous Boundaries In ShopEase, our order orchestration relies on an event-driven choreography using Apache Kafka. The lifecycle flows roughly as follows:

HTTP/REST Request: A client initiates a checkout request. Our custom CorrelationIdInterceptor intercepts the incoming request header (X-Correlation-ID), generates one if missing, and injects it into the SLF4J MDC context.

Synchronous/Service Execution: Services talk via gRPC and REST, logging actions tied directly to this correlationId.

The Asynchronous Leap (OrderSagaOrchestrator): An order is placed, and an OrderPlacedEvent is published to Kafka.

The Break: The publishing thread finishes. A completely separate consumer thread pool picks up the record from the Kafka broker to update inventory or trigger payment processing. Because standard Kafka template sends and standard listener containers do not automatically map MDC contexts across thread handoffs, the correlationId drops to null.

The Solution: Bridging Kafka Producers and Consumers with MDC To solve this without cluttering our core business logic, we leveraged Kafka’s built-in Headers mechanism combined with Spring Kafka’s interception hooks. We split the solution into two symmetrical pillars: Producer Injection and Consumer Interception.

1. Injecting the Correlation ID at the Producer Level When publishing events via KafkaTemplate, instead of relying on a bare record send, we wrap our payload inside a Kafka ProducerRecord. We read the active correlationId from the thread's MDC context and append it as a Kafka record header:

Java public void publishOrderPlacedEvent(OrderPlacedEvent event) { log.info("Publishing OrderPlacedEvent to Kafka topic '{}': {}", KafkaTopicConfig.ORDER_PLACED_TOPIC, event);

// 1. Grab current correlation ID from MDC
String correlationId = MDC.get("correlationId");

ProducerRecord<String, Object> record = new ProducerRecord<>(
    KafkaTopicConfig.ORDER_PLACED_TOPIC, 
    String.valueOf(event.getOrderId()), 
    event
);

// 2. Inject into Kafka headers if present
if (correlationId != null && !correlationId.isBlank()) {
    record.headers().add("correlationId", correlationId.getBytes(StandardCharsets.UTF_8));
}

this.kafkaTemplate.send(record);

} 2. Restoring Context via Consumer Record Interceptors On the consuming side, when a worker thread picks up the message from the queue, we intercept the incoming record before it reaches any @KafkaListener method. Using ConcurrentKafkaListenerContainerFactory#setRecordInterceptor, we extract the correlationId header and populate the worker thread's MDC context:

Java @Bean public ConcurrentKafkaListenerContainerFactory<String, Object> kafkaListenerContainerFactory( ConsumerFactory<String, Object> consumerFactory, KafkaTemplate<String, Object> kafkaTemplate) {

ConcurrentKafkaListenerContainerFactory<String, Object> factory =
        new ConcurrentKafkaListenerContainerFactory<>();
factory.setConsumerFactory(consumerFactory);

factory.getContainerProperties().setAckMode(ContainerProperties.AckMode.MANUAL_IMMEDIATE);

// Kafka Record Interceptor for Correlation ID Propagation in MDC
factory.setRecordInterceptor(record -> {
    Header header = record.headers().lastHeader("correlationId");
    if (header != null) {
        String correlationId = new String(header.value(), StandardCharsets.UTF_8);
        MDC.put("correlationId", correlationId);
    } else {
        MDC.put("correlationId", UUID.randomUUID().toString());
    }
    return record;
});

// Error handler & DLQ recoverer setup...
return factory;

} Crucial Production Note: Because consumer threads are pooled and reused across messages, failing to clear or overwrite MDC can cause context leaks (where Message B inherits Message A's trace ID). Always ensure your consumers clear or wrap logging execution contexts cleanly.

Architectural Impact & Benefits By implementing this pattern in ShopEase, we achieved:

End-to-End Observability: A single correlationId now flows seamlessly from the initial HTTP entry point, through gRPC service calls, into Kafka topics, and across downstream consumer workers.

Zero Business Logic Pollution: Developers writing event listeners don't need to manually pass or unpack tracing headers; logging frameworks pick up the trace context automatically.

Resilient Debugging: When a transaction fails and hits our Dead Letter Queue (DLQ), we can query our centralized log aggregation tool using the correlation ID and inspect the entire distributed timeline instantly.

Conclusion Distributed tracing isn't just an afterthought or an APM tool feature—it's an architectural requirement. By leveraging Kafka headers and Spring interceptors, we bridged the gap between synchronous web requests and asynchronous event-driven pipelines, making ShopEase truly enterprise-ready.

In building ShopEase (shopping-app-backend), a Spring Boot 3.x Java 17 e-commerce backend, achieving functional correctness was only half the battle. The true challenge lay in engineering a robust Testing & Quality Engineering pipeline to guarantee thread safety, zero race conditions, and predictable performance under heavy load.

The Testing & Quality Engineering Strategy To ensure zero regressions and high availability, our testing architecture covers every critical tier of the application:

Unit & Slice Testing: Isolating controllers and services using Mockito (OrderControllerTest, ProductControllerTest) to validate HTTP statuses and JSON serialization instantly.

Integration Testing: Verifying cross-component flows and database interactions (OrderServiceIntegrationTest).

Concurrency & Race Condition Testing: Simulating multi-threaded contention to prevent inventory overselling and lost updates (InventoryConcurrencyTest).

Load & Stress Testing: Automating high-traffic simulations via custom Java concurrency harnesses to measure throughput and failure rates under pressure (LoadAndStressTest).

Key Technical Highlights

1. Zero-Mock Concurrency Testing To prevent race conditions during high-demand operations, we validated thread safety using multi-threaded execution services (ExecutorService), ensuring that simultaneous updates maintain strict data consistency.
2. Lightweight Load & Stress Harness Instead of relying on heavy external CLI tools, we built an integrated Java-based load testing harness using standard HTTP clients to bombard endpoints with concurrent virtual users, measuring real-time latency, success ratios, and system stability under load.

Conclusion By implementing this comprehensive testing suite, we achieved 100% build success across all modules, robust thread safety for inventory management, and high test maintainability. Building resilient systems isn't just about clean code—it's about proving that your architecture holds up under real-world pressure.

Most beginner e-commerce projects focus on implementing CRUD operations.

Create a product. Add it to a cart. Place an order. Process a payment.

But building a backend that behaves reliably under real-world conditions requires much more than making APIs work.

What happens when multiple users try to place orders simultaneously?

How do you protect sensitive endpoints?

How should authentication tokens be managed?

And what happens when inefficient database queries start affecting application performance?

These are some of the engineering challenges I have been addressing in my ShopEase E-Commerce Backend.

During November 6–11, I focused on five major improvements involving authentication, security, database performance, and transaction management.

Let's break them down.

1. Refresh Token Rotation: Improving Authentication Lifecycle Date: November 6–8, 2026

Authentication doesn't end once a user successfully logs in.

Access tokens have limited lifetimes, and applications need a mechanism to maintain user sessions without repeatedly asking users to authenticate.

This is where refresh tokens become useful.

I worked on implementing a refresh token rotation flow in ShopEase. What changed?

• Implemented refresh token rotation logic.
• Added TokenRefresh request DTO.
• Added TokenRefresh response DTO.
• Completed endpoint wiring.
• Finalized the implementation with a stable clean build. Why does token rotation matter? A refresh token can be used to obtain a new access token.

With rotation, the application issues a replacement refresh token when the existing one is used. This helps reduce the risks associated with long-lived reusable refresh tokens.

The implementation also needs appropriate validation, expiration handling, and protection against token reuse.

The goal was to improve session lifecycle management rather than relying only on access-token authentication.

2. Cart Performance Optimization: Eliminating Inefficient Data Retrieval Date: November 8, 2026

Performance problems are not always caused by slow servers or insufficient hardware.

Sometimes, inefficient database access is the actual bottleneck.

While working on ShopEase, I focused on optimizing the buildCartResponse method. The problem Cart responses require retrieving relevant data from the database.

Inefficient retrieval patterns can introduce unnecessary database work, especially when the application needs to build responses frequently. What I changed I optimized buildCartResponse by using direct repository queries instead of table-scan-style retrieval.

The objective was to make data retrieval more targeted and reduce unnecessary database operations.

I also finalized the refresh token endpoint wiring during this milestone.

Key takeaway: Performance optimization starts with understanding what your application actually queries, not simply adding more caching infrastructure.

3. Strict JWT Authentication: Protecting Sensitive Endpoints Date: November 9, 2026

An e-commerce application contains operations that should never be exposed without appropriate authentication.

Consider these endpoints:

• /cart
• /orders
• /payments These operations involve user-specific and sensitive business data.

I strengthened JWT authentication enforcement across these areas. What changed?

• Enforced JWT authentication for cart endpoints.
• Enforced JWT authentication for order endpoints.
• Enforced JWT authentication for payment endpoints.
• Strengthened access protection for sensitive operations. Why is this important? Without appropriate authentication and authorization, an application can expose sensitive operations to unauthorized users.

JWT-based authentication provides a mechanism for validating requests using signed tokens.

However, authentication and authorization are different:

• Authentication: Who is making the request?
• Authorization: Is that user allowed to perform the requested operation? Both need to be considered when securing e-commerce APIs.

4. Security Hardening: Going Beyond JWT Date: November 10, 2026

JWT authentication is only one part of backend security.

Application configuration, browser access policies, and HTTP security headers also matter.

I strengthened the Spring Security configuration in ShopEase. Changes implemented CORS hardening

Improved CORS configuration to establish stricter cross-origin access policies.

Environment validation

Added startup validation for sensitive environment secrets.

This helps identify missing or invalid configuration before the application begins serving requests.

HTTP security headers

Integrated:

• HSTS (HTTP Strict Transport Security)
• Frame Options These headers provide additional browser-side security protections. Why does this matter? Security should not depend on a single authentication mechanism.

A more complete approach considers authentication, access control, secure configuration, and browser security policies together.

5. REPEATABLE_READ: Strengthening Checkout Transaction Consistency Date: November 11, 2026

This was one of the most interesting database-related improvements in this development cycle.

Imagine multiple customers interacting with an e-commerce system while orders are being created.

The application needs to handle concurrent transactions without allowing inconsistent database operations.

This is where transaction isolation becomes important. What is transaction isolation? Transaction isolation defines how concurrent database transactions interact with each other.

Different isolation levels provide different guarantees regarding the visibility of changes made by other transactions.

Common isolation levels include:

1. READ_UNCOMMITTED
2. READ_COMMITTED
3. REPEATABLE_READ
4. SERIALIZABLE For the ShopEase checkout flow, I configured:

REPEATABLE_READ Where did I apply it? The configuration was applied to:

OrderService.createOrder Why REPEATABLE_READ? REPEATABLE_READ helps ensure that repeated reads of the same data within a transaction remain consistent according to the database's isolation semantics.

It helps address non-repeatable read anomalies and provides stronger consistency guarantees than READ_COMMITTED.

Its exact behavior, particularly around phantom rows and locking, depends on the database engine and query type.

The objective was to strengthen transaction consistency during checkout operations, especially when multiple requests interact with order-related data.

Important: Transaction isolation alone does not prevent every possible inventory race condition or overselling scenario. Those requirements may also need atomic stock updates, locking, or optimistic concurrency control.

Complete Development Timeline Here's the progression of the recent ShopEase backend improvements. Date Area Implementation November 6 Authentication Refresh token rotation and DTOs November 8 Performance Cart response optimization and endpoint wiring November 9 Security JWT enforcement across sensitive endpoints November 10 Security CORS hardening, environment validation, HSTS and Frame Options November 11 Database REPEATABLE_READ isolation for order creation What These Improvements Mean for ShopEase These changes address different but interconnected backend engineering requirements. Engineering area Improvement Authentication Refresh token rotation API security JWT enforcement Application security CORS and HTTP security headers Configuration Startup environment validation Performance Optimized cart data retrieval Data consistency REPEATABLE_READ transaction isolationThe bigger lesson is that backend development is not just about adding endpoints.

It is about understanding how authentication, database operations, security policies, and concurrent requests interact with each other.

Final Thoughts ShopEase is gradually evolving from a basic e-commerce application into a more security-conscious and performance-focused backend system.

This development cycle taught me to look beyond whether an API returns the expected response.

I also need to consider:

• Whether the endpoint is properly protected.
• Whether the application handles tokens safely.
• Whether database queries are efficient.
• Whether concurrent transactions behave consistently.
• Whether application configuration is secure. There is still more work ahead, but these improvements represent meaningful progress toward building a reliable backend architecture.

The goal isn't just to make the application work. The goal is to understand why it works, where it can fail, and how to make it more reliable. Technologies & Concepts Java | Spring Boot | Spring Security | JWT | Refresh Token Rotation | MySQL | Redis | Transaction Isolation | CORS | REST APIs Project ShopEase — E-Commerce Web Application

About the ShopEase Project

ShopEase is a full-stack e-commerce web application that I am developing to explore real-world backend engineering challenges and modern application architecture.

The application covers the core e-commerce workflow, including:

• Product catalog and product details.
• User authentication and authorization.
• Shopping cart management.
• Order creation and management.
• Payment integration.
• Audit logging and activity tracking.
• Performance optimization and database management.

Technology Stack

The project is an ongoing practical implementation of concepts related to backend development, database architecture, security, concurrency, and system design.

Explore the Project

• Backend Repository: https://github.com/Shitanshu686/shopping-app-backend
• Frontend Repository: https://github.com/Shitanshu686/shopping-app

ShopEase is more than an e-commerce application for me; it's a practical engineering project where I experiment with backend technologies and solve real application-level challenges.

Introduction

Working on an unfamiliar open-source codebase is different from building a project from scratch.

In your own project, you already understand the architecture, naming conventions, dependencies, and execution flow. In an established project, you first need to understand how everything connects before making a change.

That was my experience while working on Issue #810 in Zerocode: Configurable Delay Executor.

I spent approximately 6–7 hours understanding the framework, tracing its execution flow, implementing the feature, debugging integration points, writing tests, and verifying the result.

In this article, I will explain the problem, the implementation, the technical decisions I made, and what I learned from this contribution.

1. Understanding the Requirement

The objective was to introduce a configurable delay executor that could pause execution for a specified number of milliseconds inside a Zerocode test scenario.

For example, consider a scenario where we need to wait for 100 milliseconds:

{ "name": "wait_for_100_ms", "url": "util://DelayExecutor", "operation": "DELAY", "request": 100, "assertions": { "status": "Success", "delayMillis": 100 } }

The expected behavior was straightforward:

Accept a delay value in milliseconds.

Validate the supplied value.

Execute the requested delay.

Return a structured response.

Integrate with the existing Zerocode scenario execution pipeline.

However, implementing this properly required understanding several parts of the framework.

2. Understanding the Existing Execution Architecture

Before implementing anything, I needed to understand how Zerocode identifies an API type and executes a scenario step.

The implementation involved multiple layers:

API URL recognition.

API type classification.

Dependency injection.

API service execution.

Multi-step scenario execution.

The important lesson was that a new executor should fit into the framework's existing architecture rather than bypassing it.

3. Creating the Delay Executor

I introduced a dedicated DelayExecutor interface:

public interface DelayExecutor {

String execute(
    String url,
    String operationName,
    String requestJson
);

}

Then I implemented DelayExecutorImpl.

The implementation uses Java's Thread.sleep() to execute the requested delay.

The core logic is:

try { Thread.sleep(delayMillis); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new IllegalStateException( "Delay execution was interrupted", e ); }

Why restore the interrupt status?

When Thread.sleep() throws InterruptedException, Java clears the thread's interrupted status.

Restoring it with:

Thread.currentThread().interrupt();

preserves the interruption signal so that higher-level code can detect that the thread was interrupted.

This was an important part of implementing interruption handling correctly.

4. Input Validation

A delay executor should not blindly accept every input.

I implemented validation for:

Null values.

Empty values.

Invalid numeric values.

Negative delay values.

The delay is parsed as a long, allowing a wider range of millisecond values than an int.

Zero is accepted as a valid delay.

Invalid inputs are rejected with meaningful exceptions rather than silently producing unexpected behavior.

5. Introducing a Dedicated API Type

One of the important integration decisions was introducing:

DELAY_CALL

I added the corresponding routing logic for:

util://DelayExecutor

The placement of this condition mattered.

It needed to be checked before the generic URL routing logic that handles other URL patterns containing ://.

Otherwise, the delay URL could be incorrectly classified as a generic Java call.

This was a useful lesson in understanding routing precedence inside an existing framework.

6. Integrating with Guice Dependency Injection

I added the binding in ApplicationMainModule:

bind(DelayExecutor.class) .to(DelayExecutorImpl.class);

This allows Guice to provide the implementation wherever the DelayExecutor interface is injected.

The benefit is separation between the interface and its implementation, while keeping the framework's existing dependency injection approach consistent.

7. Connecting the API Service Executor

I extended the API execution layer with a dedicated delay execution method.

The implementation delegates the actual work to the injected DelayExecutor.

This keeps the responsibility separated:

The scenario runner decides which operation should execute.

The API executor delegates the operation.

The delay executor performs the actual delay and creates the response.

8. Updating the Multi-Step Scenario Runner

The next step was integrating DELAY_CALL into:

ZeroCodeMultiStepsScenarioRunnerImpl

I added a dedicated case for the new API type.

When the scenario runner encounters a delay operation, it delegates the execution through the API executor instead of treating it as a normal HTTP or Java call.

This completed the connection between the JSON scenario definition and the actual delay implementation.

9. Writing Tests

Implementation alone was not enough. I needed to verify both the executor's behavior and its integration with the framework.

I added tests covering:

Unit testing

Successful delay execution and response.

Zero-millisecond delay.

Negative delay rejection.

Invalid numeric input rejection.

Null input rejection.

Interrupted execution and interrupt-status restoration.

Integration and routing testing

Recognition of util://DelayExecutor.

Case-insensitive URL recognition.

Scenario-level execution through the multi-step runner.

I also added an integration scenario fixture and documented the feature in the README.

10. Test Results

I executed the targeted Maven tests using:

mvn -pl core
-Dmaven.repo.local=E:/Maven/repository
-Dproject.build.sourceEncoding=UTF-8
-Dtest=DelayExecutorImplTest,ApiTypeUtilsTest,ZeroCodeMultiStepsScenarioRunnerImplVerifyTest
test

The result was:

Test class

Tests

Failures

Errors

DelayExecutorImplTest

6

0

0

ApiTypeUtilsTest

6

0

0

ZeroCodeMultiStepsScenarioRunnerImplVerifyTest

7

0

0

Overall:

19 tests executed.

0 failures.

0 errors.

1 skipped.

Maven build successful.

These results refer to the targeted test execution, not the entire Zerocode test suite.

11. What This Contribution Taught Me

The biggest learning was not Thread.sleep() itself. It was understanding how to introduce a feature into an established Java framework.

Working with an unfamiliar codebase

I learned to trace how an existing feature moves through different layers before deciding where new functionality belongs.

Dependency Injection

I got practical experience with Guice bindings and interface-based dependency injection.

Execution Flow

I understood how URL classification, API types, service execution, and scenario runners work together.

Thread Interruption

I learned why catching InterruptedException is not enough and why restoring the interrupt flag matters.

Testing at Different Levels

I understood the difference between testing an individual executor and testing whether the scenario runner can actually execute it.

Open-Source Contribution Workflow

I worked through the practical workflow of:

Understanding an issue.

Exploring an existing repository.

Implementing a feature on a separate branch.

Writing and running tests.

Committing and pushing changes.

Creating a pull request for maintainer review.

12. Pull Request

I submitted the implementation as:

PR #814 — Add configurable delay executor

The pull request is currently open and awaiting maintainer review.

This means the implementation has been submitted, but it has not yet been accepted or merged into the main repository.

Conclusion

This contribution gave me practical exposure to how an established Java framework is extended.

I started with an issue that appeared to require a simple delay operation. But implementing it properly meant understanding routing, dependency injection, execution layers, thread interruption, testing, and documentation.

The most valuable part of this experience was learning to work within an existing architecture instead of simply writing code that works in isolation.

I plan to continue contributing to open-source projects, improving my understanding of real-world software engineering, and learning from maintainers and other contributors.

One issue, one implementation, multiple layers of integration, and a lot of practical learning.

Understanding Polyglot Persistence through my ShopEase e-commerce backend.

When building an e-commerce application, one of the early architectural decisions is choosing a database.

For a basic application, using a single relational database might be enough. But as the application grows, different types of data introduce different requirements.

Think about it:

• Orders and payments need transactional reliability.
• Product specifications need schema flexibility.
• Frequently accessed information needs low-latency retrieval.
• Audit records need independent tracking and storage.

Should all these workloads be handled by the same database?

Technically, they could be. But should they be?

While developing ShopEase, my e-commerce application, I explored a different architectural approach: Polyglot Persistence.

Instead of forcing every type of data into one database, I integrated four technologies:

1. MySQL
2. MongoDB
3. Redis
4. PostgreSQL

Each database has a specific responsibility. Let's understand the reasoning behind this architecture.

What Is Polyglot Persistence?

Polyglot Persistence is an architectural approach in which an application uses multiple database technologies based on the requirements of different data types and workloads.

The idea is simple:

Don't choose a database just because it's popular. Choose it because it fits the problem.

A relational database may be excellent for transactional operations, while a document database may be more suitable for flexible data structures.

Similarly, an in-memory data store can handle frequently accessed information more efficiently than repeatedly querying a persistent database.

This is the principle I followed while designing ShopEase.

1. MySQL — Protecting the Core Business Transactions

Let's start with the most important part of an e-commerce application: business transactions.

ShopEase manages data such as:

• User information
• Orders
• Payments
• Cart records
• Other relational entities

These operations require reliable data management.

Imagine a customer placing an order. The application must maintain consistency between related records. A payment or order operation cannot be treated like an ordinary cache lookup.

That's why I selected MySQL as the primary relational database.

Why MySQL?

ACID properties: MySQL supports transactional operations that help maintain data consistency and reliability.

Relational integrity: Foreign keys and constraints help maintain relationships between entities.

Joins: Relational queries make it easier to retrieve connected business data.

Structured data: Users, orders, and payments naturally fit relational data models.

MySQL acts as the transactional backbone of ShopEase.

The goal was to keep critical business data in a relational system with well-defined relationships and transaction support.

2. MongoDB — Handling Products That Don't Have Identical Attributes

Here's an interesting challenge with e-commerce applications.

Consider these two products:

Product A: Smartphone

• RAM
• Internal Storage
• Processor
• Battery Capacity
• Camera

Product B: T-shirt

• Size
• Color
• Fabric
• Fit
• Sleeve Type

Now imagine storing every possible product attribute in a single rigid relational structure.

As the product catalog grows, new categories introduce new specifications. Maintaining a flexible product model becomes increasingly important.

This is where MongoDB becomes useful.

Why MongoDB?

MongoDB stores data in document-oriented structures, making it suitable for product information that varies across categories.

Its advantages include:

• Flexible document structure.
• Different attributes for different product categories.
• Easier evolution of product specifications.
• Convenient storage and retrieval of category-specific information.

In ShopEase, MongoDB is used for dynamic product details, while the core relational data remains in MySQL.

The important distinction is that not every product needs to follow the same data structure.

3. Redis — Reducing Repeated Database Queries

Performance is another important consideration.

Imagine a user repeatedly accessing the same product information or interacting with their cart.

If every frequently repeated operation results in a database query, unnecessary database load can accumulate.

To address low-latency requirements, I integrated Redis.

Redis is an in-memory data store that provides very fast data access.

Why Redis?

I use Redis for performance-oriented responsibilities such as:

• Caching frequently accessed information.
• Session-related data management.
• Cart-related operations.
• Rate limiting.

The primary benefit is reducing repeated access to persistent databases when cached data can be reused.

For example:

1. A user requests frequently accessed product information.
2. The application checks Redis for cached data.
3. If valid cached data exists, it can be returned directly.
4. Otherwise, the application retrieves the data from the appropriate persistent database and may cache it for subsequent requests.

This is commonly known as the Cache-Aside Pattern.

Redis is not replacing MySQL or MongoDB. It is supporting them by handling suitable low-latency workloads.

4. PostgreSQL — Giving Audit Logs Their Own Home

A reliable application should not only manage business transactions; it should also maintain a record of important activities.

For example:

• Which user performed an operation?
• Which entity was modified?
• What action was performed?
• When did the activity happen?

These records are important for debugging, activity tracking, and security-related investigations.

For ShopEase, I introduced PostgreSQL as a dedicated audit-log database.

Why PostgreSQL?

The main architectural reason was separation of concerns.

Instead of mixing audit records with the application's primary business data, I wanted an independent store for audit-related information.

This provides:

• Dedicated storage for audit records.
• Structured querying of activity history.
• Separation between business data and audit data.
• Independent management of audit-related workloads.

The objective is to isolate audit data management from the core transactional data model.

One important distinction: using a separate database alone does not automatically make audit writes asynchronous or guarantee that business transactions will never wait for them. That also depends on how the application implements the audit-writing process.

How All Four Databases Work Together

Here's the responsibility breakdown in ShopEase:

Each technology serves a different purpose.

The objective isn't to make every database communicate with every other database. The objective is to assign responsibilities clearly and make the application use the appropriate storage system for each requirement.

Was Using Four Databases Really Necessary?

This is an important architectural question.

Using multiple databases also introduces complexity.

For example:

• More configuration and infrastructure to maintain.
• Multiple database connections.
• Different data models and query mechanisms.
• Additional monitoring and debugging requirements.
• More complicated backup and recovery planning.
• Potential consistency challenges across systems.

A single database would have been simpler to operate.

However, ShopEase was also an opportunity to explore how different storage technologies address different application requirements.

I didn't introduce four databases because more databases automatically mean better performance or scalability.

I introduced them to understand and implement Polyglot Persistence in a practical e-commerce application.

The trade-off is clear: greater flexibility and workload separation in exchange for additional operational complexity.

Final Thoughts

Building ShopEase helped me understand that database selection is not just about choosing between SQL and NoSQL.

It's about understanding the nature of the data, the operations performed on it, and the requirements of the system.

MySQL handles transactional business data.

MongoDB handles dynamic product information.

Redis supports low-latency access.

PostgreSQL maintains a dedicated audit trail.

Four databases, one application, and four different responsibilities.

That's how I approached database architecture in ShopEase.

The biggest takeaway?

Good system design isn't about using more technologies. It's about using the right technology for the right problem.

Technologies Used

• Java
• Spring Boot
• MySQL
• MongoDB
• Redis
• PostgreSQL
• Spring Data JPA
• Spring Data MongoDB
• Spring Data Redis

Project

ShopEase — E-Commerce Web Application

#Java #SpringBoot #MySQL #MongoDB #PostgreSQL #Redis #PolyglotPersistence #BackendDevelopment #SystemDesign #Ecommerce #ShitanshuJha

A single database and tightly coupled services aren't always the best fit for every workload. While working on ShopEase, my full-stack e-commerce project, I worked on a backend architecture that separates storage responsibilities and decouples downstream processing using Apache Kafka.

This engineering work focuses on three areas:

• Polyglot Persistence Architecture
• CQRS-inspired, event-driven processing
• An isolated asynchronous compliance and audit pipeline

Let's explore the architecture and the problems these patterns are designed to address.

1. Polyglot Persistence: The Right Database for the Right Job

Different types of application data have different requirements. Transactional records, dynamic product attributes, and compliance logs don't necessarily benefit from the same storage model.

For ShopEase, I designed a hybrid storage architecture using three database technologies.

MySQL 8.4 — Core Transactional Data

Orders, payments, and inventory require reliable transactional operations and consistency.

MySQL handles these core transactional workloads, where ACID transactions are important for maintaining data integrity.

MongoDB — Dynamic Product Catalog

Product catalogs can contain different attributes depending on the product category. A laptop, a T-shirt, and a smartphone don't necessarily share the same fields.

MongoDB's BSON document model supports flexible, polymorphic product structures without forcing every product into an identical document shape.

PostgreSQL — Compliance and Audit Logs

Audit records have different access and retention requirements from transactional application data.

For this pipeline, PostgreSQL stores append-only compliance logs using JSONB, with GIN indexing to support queries over relevant JSON fields.

The architectural principle: choose storage based on the workload, data structure, and consistency requirements—not simply because a particular database is popular.

2. CQRS-Inspired Processing with Apache Kafka

Checkout workflows can involve several downstream operations: payment processing, inventory updates, notifications, and audit events.

Coupling all of these operations directly to the checkout request can increase dependencies and make failures harder to isolate.

In ShopEase, I worked on an event-driven design using Apache Kafka to decouple primary checkout processing from downstream services.

The high-level flow is:

1. A checkout request enters the order-processing workflow.
2. The relevant event is published to Kafka.
3. Downstream consumers process events for their respective responsibilities.
4. Payment, inventory, and notification processing can proceed independently of the synchronous request path where the workflow permits.
5. Failed event processing can be routed through retry or Dead Letter Queue (DLQ) handling.

The implementation also uses manual Kafka offset acknowledgements, allowing message acknowledgement to be coordinated with processing outcomes.

This requires careful handling of retries and duplicate deliveries. Kafka delivery guarantees alone do not automatically make database updates or external payment operations idempotent.

Where CQRS fits

CQRS separates command responsibilities from query responsibilities. It is not synonymous with Kafka or microservices.

In ShopEase, the event-driven decoupling supports a CQRS-inspired architectural approach. The exact command/query separation depends on how individual read and write models are implemented.

3. An Isolated Asynchronous Audit Pipeline

Audit logging can introduce additional database writes into application workflows. If those writes share critical request-processing resources, they can contribute to contention and additional latency.

To address this architectural concern, I worked on an asynchronous audit ingestion pipeline using Spring's @Async and dedicated secondary data sources.

The intended processing flow is:

Application events → Audit listener → Asynchronous processing → PostgreSQL audit storage

This separates audit-write responsibilities from the core transaction-processing path.

The design aims to:

• Reduce coupling between core business operations and audit persistence.
• Keep audit ingestion off the main request-processing thread where configured.
• Store structured audit data using PostgreSQL JSONB.
• Support JSON-field queries using appropriate GIN indexes.
• Improve traceability and operational separation.

One important engineering consideration is reliability: asynchronous execution alone does not guarantee that every audit event will be persisted. Durable event delivery, retry policies, monitoring, and failure recovery must be considered according to the compliance requirements.

4. Putting the Architecture Together

The main components of this ShopEase backend architecture are:

• Spring Boot: application services and backend APIs.
• MySQL 8.4: core transactional data.
• MongoDB: flexible product catalog documents.
• PostgreSQL: compliance and audit records.
• Apache Kafka: asynchronous event-driven communication.
• Spring @Async: asynchronous audit processing.
• JSONB and GIN indexes: structured audit data and JSON-oriented query support.

Each component has a distinct responsibility, helping the architecture address different data and processing requirements.

5. Key Engineering Lessons

Working on these architectural patterns reinforced several important backend engineering principles:

Database selection is a design decision. Multiple databases can be useful when workloads have genuinely different requirements, but they also introduce operational complexity.

Asynchronous processing changes failure handling. Retries, duplicate events, offset acknowledgement, and dead-letter handling need deliberate design.

Audit logging deserves its own reliability strategy. Separating audit ingestion can reduce coupling, but durability and recovery must be designed explicitly.

Distributed systems require observability. Logs, metrics, traces, and consumer-lag monitoring help identify problems across service boundaries.

What's Next?

The next step is to strengthen this architecture through integration testing, failure-injection tests, end-to-end tracing, and reproducible performance benchmarks. These help validate not just whether individual components work, but whether the complete system behaves correctly under failures and concurrent workloads.

About ShopEase

ShopEase is a full-stack e-commerce application developed by Shitanshu Jha, focused on Java backend engineering, database design, secure transactions, performance optimization, and scalable application architecture.

GitHub repositories:

• ShopEase Backend
• ShopEase Frontend

Building ShopEase has been a practical journey in understanding the trade-offs behind modern backend systems—and turning architectural concepts into implementation work.

Overview

As part of my ShopEase e-commerce project, I worked on improving backend performance by optimizing the catalog and order data pipelines. The goal was to reduce read latency, eliminate inefficient database queries, improve connection management, and make data retrieval more efficient.

Key Optimizations

1. Redis Cache-Aside

Implemented a Redis Cache-Aside layer for catalog and order pipelines, along with automated cache invalidation to keep cached data consistent with updates.

Reported result: Read latency reduced from 1.88 seconds to 110 milliseconds — a 94% reduction.

2. Hibernate N+1 Query Optimization

Resolved Hibernate N+1 query bottlenecks using JOIN FETCH, allowing related data to be retrieved more efficiently and reducing unnecessary database round trips.

3. HikariCP Connection Pool Tuning

Optimized HikariCP connection pool settings to improve database connection management and resource utilization.

4. MySQL Composite B-Tree Indexes

Introduced composite B-Tree indexes to improve query execution efficiency and reduce unnecessary row scans.

Reported result: MySQL query row-scans reduced by 95%.

Technology Stack

• Language: Java

• Backend: Spring Boot, Hibernate, Spring Data JPA

• Database: MySQL

• Caching: Redis

• Connection Pooling: HikariCP

• Query Optimization: JOIN FETCH and composite B-Tree indexes

What I Learned

This optimization work reinforced that backend performance depends on multiple layers working together. Caching reduces repeated database reads, efficient ORM queries help avoid unnecessary round trips, connection pooling improves resource management, and indexing makes data retrieval more efficient.

Conclusion

Improving ShopEase was not just about adding features; it was also about making existing functionality faster and more efficient. These optimizations strengthened my practical understanding of Java backend development, database performance tuning, caching strategies, and scalable application design.

Engineered a multi-tier performance optimization for catalog and order pipelines: implemented a Redis Cache-Aside layer cutting read latency by 94% (1.88s → 110ms) with automated cache invalidation, resolved Hibernate N+1 query bottlenecks via JOIN FETCH, tuned HikariCP connection pooling, and introduced composite B-Tree indexes reducing MySQL query row-scans by 95%.

About ShopEase ShopEase is a full-stack e-commerce application built with Java, Spring Boot, MySQL, and Redis. It focuses on secure shopping, efficient data management, and high-performance backend architecture.

Developed by Shitanshu Jha 💻

Project: ShopEase — Full-Stack E-Commerce Application

GitHub — Backend: https://github.com/Shitanshu686/shopping-app-backend

GitHub — Frontend: https://github.com/Shitanshu686/shopping-app

As part of my ShopEase e-commerce backend project, I worked on improving concurrency handling, transaction management, and checkout reliability using Java, Spring Boot, Spring Data JPA, and MySQL.

Why This Module Matters

Imagine a product has only one item left in stock, but two customers attempt to purchase it at almost the same time.

Without proper concurrency control, both requests might read the same stock value and attempt to complete their purchases. This can lead to overselling and inconsistent inventory.

A similar issue can occur when a checkout request is submitted multiple times because of repeated clicks, network delays, or client retries.

This module focuses on addressing these challenges.

1. Multiple Database Concurrency Strategies

I implemented different approaches to handle concurrent inventory updates in DatabaseConcurrencyService.

Atomic SQL Updates

Atomic SQL updates allow the database to perform stock modifications as a single operation rather than relying on separate read-and-write steps in application code.

For example:

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

The query checks stock availability and deducts the requested quantity in one database statement.

The application can inspect the affected-row count to determine whether the update succeeded.

Key benefit: Reduces the risk of race conditions during inventory deduction without requiring the application to read and modify the stock in separate steps.

Pessimistic Locking

Pessimistic locking is useful when a transaction needs to lock a database record while performing an operation.

With JPA, a repository method can use LockModeType.PESSIMISTIC_WRITE to request a write lock on the selected entity.

This helps prevent competing transactions from modifying the same locked record simultaneously.

Key benefit: Provides controlled access to inventory records when conflicting updates are likely.

Optimistic Locking

Optimistic locking assumes that conflicting updates are relatively uncommon and detects conflicts when they occur.

I added a version column to support JPA version-based locking:

@Version
private Long version;

Hibernate uses this version information to detect conflicting updates. If another transaction changes the entity first, the stale update can fail instead of silently overwriting newer data.

Key benefit: Helps maintain data consistency without holding a pessimistic lock for the entire operation.

Each strategy has different trade-offs, so the right choice depends on transaction duration, contention, and workload.

2. Preserving Transaction Boundaries in Executor Threads

Asynchronous execution introduces an important Spring transaction-management consideration.

Spring commonly manages @Transactional behavior through proxies. Calling a transactional method through the Spring proxy allows the transaction interceptor to apply.

However, invoking a method through this within the same object can bypass that proxy.

I implemented self-proxy injection so that calls to transactional methods can go through the Spring-managed proxy, including when the work is executed in executor threads.

This helps preserve the intended transaction interception behavior.

It is also important to understand that transactions do not automatically propagate to a newly created executor thread. The transactional method needs to establish its own transaction when invoked through the appropriate proxy.

Key lesson: Thread management and transaction management must be designed together when implementing concurrent database operations.

3. Native Atomic Queries in ProductRepository

I added a native atomic stock-update query in ProductRepository.

Instead of loading an entity, changing its stock in Java, and then saving it, the database can perform the conditional update directly.

This can reduce application-side read-modify-write operations and improve throughput under suitable workloads.

However, atomic SQL updates do not eliminate every form of database locking. Databases still use the locks and concurrency mechanisms required to execute the statement safely.

The important advantage is that the stock condition and deduction happen within one database operation.

4. Idempotency-Key Validation for Checkout

A checkout request may be repeated because of network timeouts, retries, or repeated button clicks.

Without duplicate-request protection, the same logical checkout attempt could trigger unwanted repeated processing.

I implemented IdempotencyKey validation to detect duplicate checkout requests and return HTTP 409 Conflict when a duplicate is detected.

The intended flow is:

1. The client submits a checkout request with an idempotency key.

2. The backend validates the key.

3. A new request proceeds through checkout processing.

4. A duplicate request is rejected with HTTP 409 Conflict.

For a production-grade implementation, the key must be stored and checked atomically, usually with a database uniqueness constraint. Its scope, expiration, request association, and behavior after failures must also be defined.

Idempotency protection should cover the actual checkout side effects, not merely the initial request validation.

Key benefit: Helps prevent duplicate checkout processing caused by repeated requests.

5. JPA Versioning and Bean Collision Resolution

I added a version column to support optimistic locking and resolved a Spring bean collision encountered during application configuration.

The @Version field allows JPA/Hibernate to detect stale updates. This is especially important when multiple transactions attempt to update the same product.

Resolving the bean collision also helps the Spring application context initialize with the intended configuration.

These changes strengthen both database consistency and application stability.

What I Learned

This module reinforced several important backend engineering concepts:

• Atomic database operations can simplify concurrent inventory updates.

• Pessimistic and optimistic locking solve different concurrency problems.

• Spring transaction proxies affect how transactional methods are invoked.

• Executor threads require deliberate transaction-boundary management.

• Idempotency requires reliable duplicate detection around checkout side effects.

• JPA versioning helps detect conflicting updates instead of silently overwriting data.

Conclusion

The goal of this ShopEase milestone was to improve the reliability of inventory updates and checkout processing under concurrent requests.

By implementing atomic SQL updates, pessimistic and optimistic locking, self-proxy injection, idempotency validation, and JPA versioning, I strengthened the backend's approach to concurrency control and data consistency.

This work is another step toward building a more reliable and production-oriented e-commerce backend with Spring Boot.

Tech Stack: Java · Spring Boot · Spring Data JPA · Hibernate · MySQL · SQL · Multithreading

#Java #SpringBoot #BackendDevelopment #Concurrency #MySQL #Ecommerce #ShopEase

• 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

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

💳 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

API Gateway Product Service User Service Cart Service Order Service Payment Service Apache Kafka for event-driven communication

The main objective wasn't just creating separate services. The real challenge was making sure these services could communicate reliably and handle asynchronous events correctly.

🔧 What Problem Did I Solve?

In a monolithic backend, different components can communicate directly within the same application.

With microservices, each service is separated. This creates new problems:

How does a request reach the correct service?

How does one service communicate with another?

What happens when communication is asynchronous?

How can services react to events without being tightly coupled?

For ShopEase, I addressed these problems by introducing an API Gateway for routing and using service-to-service communication along with Apache Kafka for event-driven communication.

For example, instead of making every service directly responsible for handling everything, events can be published and consumed by the services that need them.

⚙️ Challenges I Faced

The biggest learning came from debugging the integration rather than simply writing the code.

Some of the challenges included:

1. API Gateway Routing

Making sure requests were correctly routed from the gateway to the appropriate microservice required proper configuration and testing.

A small routing or path configuration issue could make an otherwise working service appear to be unavailable.

1. Service-to-Service Communication

Each service worked independently, but integration introduced another layer of complexity.

I had to verify that one service could correctly communicate with another and that the expected request/response flow was working.

1. Kafka Event Communication

Working with Kafka was different from normal synchronous REST communication.

Instead of:

Service A → Service B → Response

the flow could become:

Service A → Kafka → Event → Service B

Understanding producers, consumers, topics and asynchronous processing was an important part of this module.

1. Debugging Distributed Systems

One of the harder parts was identifying where a problem actually occurred.

When something failed, the issue could be inside the gateway, the calling service, the receiving service, Kafka configuration, or the event-consumer side.

This forced me to stop looking at the application as one single backend and start thinking in terms of multiple independently running services.

🧪 Testing & Verification

After integration, I tested the communication flow between the services and verified that the expected requests and events were reaching their respective destinations.

The goal was not simply:

“The services are running.”

The goal was:

“The services are communicating and behaving as expected.”

This distinction became one of the biggest takeaways from the module.

🧠 What I Learned

This module gave me a much better understanding of what actually changes when moving from a traditional backend architecture toward microservices.

I learned that microservices are not simply about splitting one application into multiple projects.

They introduce challenges around:

Service communication API routing Asynchronous processing Event-driven architecture Failure debugging Distributed system testing Service dependencies

The biggest lesson for me was that distributed systems solve some problems while introducing completely new ones.

🚀 Another ShopEase Milestone

Completing Module 30.11 was an important step in my ShopEase backend journey because I moved beyond developing individual features and started working with distributed backend architecture.

There is still more to explore, especially around deployment, production configuration, scalability, fault tolerance and concurrency.

But this module gave me practical exposure to how multiple backend services can work together as one larger system.

Tech Stack: Java | Spring Boot | Microservices | API Gateway | Apache Kafka | REST APIs | Distributed System

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. 🚀

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

ShopEase is a full-stack e-commerce application designed to simulate the functionality of a real-world shopping platform.

Its architecture currently follows:

Frontend HTML / CSS / JavaScript ↓ Fetch API ↓ Spring Boot REST API ↓ Spring Security + JWT ↓ Spring Data JPA / Hibernate ↓ MySQL

The project already includes authentication, authorization, products, cart, wishlist, orders, payments, admin functionality, inventory management, validation, exception handling and logging.

After completing the major business features, I started focusing on an important question:

How can I make the application handle real-world data and usage more efficiently?

That led to the next three modules.

🚀 Module 25 — Pagination & Sorting The Problem

Imagine an e-commerce application has 10,000 products.

If the API returns every product whenever the user opens the product page, the application has to:

Fetch a large amount of data. Transfer unnecessary data to the client. Process more records than required. Potentially increase response time.

Users don't need 10,000 products at once.

They might only need 10 or 20 products per page.

The Solution

I implemented Pagination and Sorting using Spring Data JPA.

The important concepts are:

Pageable Page Sorting

Instead of requesting everything:

GET /products

the application can request a specific page and size.

Conceptually:

Page 1 → Products 1–10 Page 2 → Products 11–20 Page 3 → Products 21–30

Sorting can also be applied according to requirements such as:

Price → Low to High Price → High to Low Name → A-Z Rating → Highest First Why this matters

Pagination reduces the amount of data processed and returned in a single request.

This becomes increasingly important as the number of products grows.

🔎 Module 26 — Search & Filtering The Problem

Pagination solves the problem of too many results, but there is another problem.

Suppose a customer wants:

"Show me highly-rated mobile products from a particular brand within my budget."

Simply displaying pages of products isn't enough.

The user needs to find relevant products quickly.

The Solution

I implemented product Search & Filtering based on:

Product Name Category Brand Price Rating Multiple filters

This allows the application to narrow down the product dataset according to the user's requirements.

For example:

Category = Mobile Brand = Samsung Price = ₹20,000 – ₹40,000 Rating = 4★+

Instead of returning the complete product catalogue, the backend returns only products matching the requested conditions.

Multiple Filters

One important part is combining multiple conditions.

For example:

Category AND Brand AND Price Range AND Rating

This makes the product catalogue much more useful from a customer's perspective.

🖼️ Module 27 — Image Upload The Problem

A product catalogue isn't useful if products don't have proper images.

Initially, product data can simply contain text such as:

name price category brand rating

But an actual e-commerce platform also needs product images.

The backend therefore needs to accept an uploaded file, store/manage it and provide a URL that can be used by the frontend.

The Solution

I implemented product image handling using:

MultipartFile Image Upload/Storage Image URLs Product Image Management

The basic flow is:

Admin selects image ↓ MultipartFile ↓ Spring Boot Backend ↓ Image Storage ↓ Image URL ↓ Product ↓ Frontend displays image

This separates the concept of product data from the actual image file while allowing the product to reference its image through a URL.

🧩 What Problems Do These Modules Solve?

These three modules address very different problems:

Feature Problem Solved Pagination Too many products being returned at once Sorting Users need results in a useful order Search Users need to find specific products Filtering Users need to narrow down results Image Upload Products need visual representation

Together, they make the application much closer to how users expect a modern e-commerce platform to behave.

⚙️ Challenges & Engineering Considerations

While implementing these modules, the main engineering challenges are not simply writing a few methods. The bigger challenge is designing the functionality so that it works correctly as the application grows.

1. Handling large datasets

Pagination needs to be applied at the database/query level, rather than loading every product into memory and manually splitting the list.

1. Combining filters

When several filters are provided together, the backend needs to correctly combine the conditions instead of treating each filter independently.

For example:

Category + Brand + Price + Rating

should produce one meaningful result set.

1. Optional filters

Not every request will contain every filter.

A user might search only by:

brand

while another request might contain:

brand + category + price + rating

The backend therefore needs to handle different combinations cleanly.

1. File handling

Image uploads are different from normal JSON requests.

The backend needs to handle:

multipart/form-data

and process the uploaded file through MultipartFile.

1. Maintaining clean API design

Adding features shouldn't turn the controller into a large block of business logic.

Keeping responsibilities separated between the Controller, Service and Repository layers makes the application easier to maintain.

📈 What These Modules Taught Me

These modules helped me understand an important difference between:

“An application that works”

and

“An application designed to handle real-world usage.”

A basic product API may work perfectly with 20 products.

But what happens when there are:

20 products? ↓ 2,000 products? ↓ 20,000 products?

That's where decisions such as pagination, filtering, efficient querying and proper file handling become important.

This is the direction I'm trying to take ShopEase in.

🛠️ Technology Stack

Backend

Java Spring Boot Spring MVC Spring Data JPA Hibernate

Database

MySQL

Security

Spring Security JWT BCrypt

Frontend

HTML CSS JavaScript Fetch API

Tools

Eclipse Postman Git GitHub XAMPP 🔮 What's Next?

With Modules 25–27 completed and tested, my next focus is continuing the production-hardening phase of ShopEase.

The upcoming roadmap includes:

Module 28 — Docker

Containerizing the application.

Module 29 — CI/CD

Building an automated build, test and deployment workflow.

Module 30 — Deployment

Deploying the application to a cloud platform.

Module 31 — Monitoring & Logging

Application monitoring, centralized logging and error tracking.

🎯 Final Thoughts

ShopEase started as a project for learning Java and Spring Boot, but it has gradually become a way for me to understand how different parts of a real software system fit together.

Pagination taught me about handling growing datasets.

Search and filtering taught me about making large datasets useful.

Image upload introduced another type of data that a backend application needs to handle.

The next goal is to take the same approach toward testing, documentation, containerization, CI/CD and deployment.

The goal isn't just to keep adding features. The goal is to keep making the application better engineered.

#Java #Spring Boot #Spring Data #JPA #Hibernate #MySQL #REST API #Backend Development #E-Commerce #Pagination #Search #Filtering #Image Upload #Software Development

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

• Similar products

• Shopping cart and persistent cart

• Wishlist

• Checkout and shipping address

• Orders and order history

• Order status management

• Product feedback and moderation

• Razorpay payments

• Payment verification and signature validation

• Admin dashboard

• User, product and order management

• Inventory management

• Low-stock and out-of-stock alerts

• Application logging

• Standard API responses

• DTO-based validation and exception handling

The project has also given me practical experience with tools such as Git, GitHub, Eclipse, Postman and XAMPP.

What I Learned From Building It

The biggest lesson hasn't been learning another framework.

It has been learning how different parts of software interact.

For example, implementing authentication taught me about JWTs and Spring Security. Building the cart and order systems forced me to think about relationships between entities and persistent data. Razorpay integration introduced payment verification and security concerns.

Admin functionality made me think beyond the customer's experience and consider inventory, order management and authorization.

Logging also showed me why knowing that an application failed isn't enough — developers need useful information about where and why it failed.

My Current Focus

I am now moving from feature development toward production hardening.

My next areas of focus are:

• Automated testing

• API documentation with OpenAPI/Swagger

• Pagination and sorting

• Advanced search

• Image upload

• Docker

• CI/CD

• Deployment

• Cloud deployment

The goal is no longer just to make an application that works.

The goal is to understand how to make an application that is testable, maintainable, secure, deployable and closer to production standards.

What's Next?

I am still at the beginning of my career, and I know there is a lot more to learn.

My current direction is clear:

Java → Spring Boot → Backend Engineering → Production Systems

I want to keep building projects, solving problems, improving my understanding of backend architecture and gradually working with larger and more complex systems.

ShopEase is not the final destination.

It is the project through which I am learning how to become a better software developer.

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