DEV Community: Anuj Ashok Potdar

Building Fault-Tolerant Order Processing with Paxos in a Distributed E-Commerce Store 🚀

Anuj Ashok Potdar — Sun, 27 Apr 2025 20:49:06 +0000

In a distributed e-commerce system, ensuring that each order is processed exactly once—even when servers crash or messages get lost—is crucial. In this post, I’ll walk you through how the Paxos consensus algorithm is used in my Spring Boot backend to coordinate order creation across multiple servers and guarantee fault tolerance.

Why Paxos?

Consistency under failures: Even if some nodes crash or the network is unreliable, Paxos ensures that a single, agreed-upon value (here, the “create order” operation) is chosen exactly once.
No single point of failure: Any node can propose an order, and the algorithm will still reach consensus as long as a majority of nodes are up.
Asynchronous & leaderless: There’s no fixed leader; any node can initiate the consensus process.

High-Level Flow

Proposal: A client sends an order request (wrapped in a Proposal) to a set of Paxos servers.
Promise: Each server replies with a Promise if it hasn’t promised a higher-numbered proposal.
Accept: Once the proposer gathers a majority of promises, it sends an accept request.
Learn: After a majority of servers accept, they “learn” the chosen operation and execute it (create the order).

Key Interface

All Paxos servers implement a simple interface (from com.arm.coordinator.common.PaxosServer<T>):

public interface PaxosServer<T> {
  Promise promise(Proposal proposal);
  Boolean accept(Proposal proposal);
  Result learn(Proposal proposal, Integer userId);
}

The Promise Phase

The promise(...) method ensures that no server will accept proposals older than the one it has already promised. In your PaxosOrderService:

@Override
public synchronized Promise promise(Proposal proposal) {
  serverLogger.info("Receive a promise message");
  if (proposal.getId() <= this.maxId) {
    return new Promise(Status.REJECTED, null);
  }
  this.maxId = proposal.getId();
  if (this.accepted != null) {
    // If we’ve already accepted something, let the proposer know
    return new Promise(Status.ACCEPTED,
          new Proposal(accepted.getId(), accepted.getOperation()));
  } else {
    // Otherwise, promise not to accept lower proposals
    return new Promise(Status.PROMISED, proposal);
  }
}

(distributed-ecommerce-store/app/src/main/java/com/arm/ecommerce/service/PaxosOrderService.java at main · anizmo/distributed-ecommerce-store · GitHub)

Here, maxId tracks the highest proposal ID seen so far. If the incoming proposal is newer, we record it and either report back the already-accepted proposal or promise to accept it later.

The Accept Phase

Once a proposer has a majority of PROMISED responses, it issues an accept request:

@Override
public synchronized Boolean accept(Proposal proposal) {
  serverLogger.info("Received an accept message");
  if (proposal.getId() != this.maxId) {
    // Only accept if this is the latest promised proposal
    return false;
  }
  // Record that we’ve accepted this proposal
  accepted = new Proposal(proposal.getId(), proposal.getOperation());
  serverLogger.info("Proposal successfully accepted");
  return true;
}

(distributed-ecommerce-store/app/src/main/java/com/arm/ecommerce/service/PaxosOrderService.java at main · anizmo/distributed-ecommerce-store · GitHub)

By checking proposal.getId() == maxId, we ensure consistency: servers will only accept the proposal they most recently promised.

The Learn Phase

After a majority of servers accept, the operation is “learned” and executed exactly once:

@Override
public synchronized Result learn(Proposal proposal, Integer userId) {
  serverLogger.info("Received a learn message");
  OrderForm form = proposal.getOperation().getOrderForm();
  // Validate products, create Order and OrderProducts atomically
  Order order = orderService.create(new Order(...));
  // ... attach products, set status, etc.
  Result result = new Result(true, ResultCodeEnum.ALL_OKAY, "Order created successful");
  return result;
}

(distributed-ecommerce-store/app/src/main/java/com/arm/ecommerce/service/PaxosOrderService.java at main · anizmo/distributed-ecommerce-store · GitHub)

This final step writes the order to the database only once, even if some servers already crashed after accepting.

Why This Solves Fault Tolerance

Majority Quorum: As long as a majority of servers respond, the proposal moves forward. Crashed or slow nodes can catch up later.
Exactly-Once Semantics: By separating promise, accept, and learn phases, you avoid double-creation even if messages are retried.
Recovery: New or recovering servers can learn the last accepted proposal and apply it to reach the same state.

Next Steps & Extensions

Persistent State: Store maxId and accepted in durable storage so servers can recover after a full restart.
Leader Election: Build a distinguished proposer to reduce round-trip latency.
Batching: Group multiple operations per consensus round for higher throughput.

By weaving Paxos into your order service, you transform a vanilla Spring Boot app into a rock-solid, fault-tolerant distributed system. Feel free to explore the full code and fork it here:

👉 github.com/anizmo/distributed-ecommerce-store

Happy coding! ✨

Spring PetClinic Goes Global: Enhancing Accessibility with Multi-Language Support

Anuj Ashok Potdar — Sun, 27 Apr 2025 19:05:22 +0000

Introduction

The Spring PetClinic application is a flagship example of Spring Boot best practices, used by developers worldwide to learn enterprise patterns. Recently, my pull request (#0c88f9) was merged, introducing a critical feature: full internationalization (i18n) support using URL-based language switching. This update not only makes the application accessible to non-English speakers but also modernizes its architecture for scalability. Let’s explore why this matters.

The Problem: Limited Language Support

Before this change, Spring PetClinic lacked robust support for multiple languages. While it included basic message properties, it didn’t fully leverage Spring’s i18n capabilities, making it difficult to:

Switch Languages Dynamically: Users couldn’t change languages via the URL, a common requirement for global applications.
Maintain Consistency: Hardcoded text in HTML files made translations error-prone and fragmented.
Scale to New Languages: Adding a new language required manual updates across HTML templates, violating the DRY (Don’t Repeat Yourself) principle.

For a reference application like PetClinic, this was a missed opportunity to demonstrate scalable i18n practices.

The Solution: URL-Based Localization and Decoupled Text

The commit introduces three key improvements:

1. Dynamic Language Switching via URL Parameters

A new WebConfiguration class configures Spring’s LocaleResolver to read the lang parameter from URLs (e.g., ?lang=es). This allows users to bookmark or share language-specific links, aligning with RESTful principles.

@Configuration  
public class WebConfiguration implements WebMvcConfigurer {  
    @Bean  
    public LocaleResolver localeResolver() {  
        SessionLocaleResolver slr = new SessionLocaleResolver();  
        slr.setDefaultLocale(Locale.ENGLISH);  
        return slr;  
    }  

    @Bean  
    public LocaleChangeInterceptor localeChangeInterceptor() {  
        LocaleChangeInterceptor lci = new LocaleChangeInterceptor();  
        lci.setParamName("lang");  
        return lci;  
    }  

    @Override  
    public void addInterceptors(InterceptorRegistry registry) {  
        registry.addInterceptor(localeChangeInterceptor());  
    }  
}

2. Centralized Message Properties

All UI text was moved to messages.properties files (e.g., messages_es.properties, messages_fr.properties), decoupling content from presentation. This ensures translations are maintained in a single location.

Example (messages_es.properties):

welcome=¡Bienvenido a PetClinic!  
owners=Propietarios  
find_owners=Buscar Propietarios

3. HTML Template Cleanup

Hardcoded text in Thymeleaf templates was replaced with Spring’s #{...} expressions, enabling dynamic resolution based on the user’s locale:

<!-- Before -->  
<h2>Find Owners</h2>  

<!-- After -->  
<h2 th:text="#{find_owners}">Find Owners</h2>

Architectural Impact: Why This Matters

1. Scalability for Global Audiences

By supporting URL-driven language switching, PetClinic now serves as a blueprint for building globally accessible applications. Developers can easily add new languages by creating a messages_xx.properties file—no code changes required.

2. Separation of Concerns

Decoupling text from HTML templates follows the MVC pattern rigorously. Content editors can now manage translations without touching Java code or Thymeleaf markup.

3. Improved Maintainability

Centralized message properties reduce duplication and make it easier to spot missing translations. For example, adding support for Japanese (messages_ja.properties) becomes a trivial task.

4. Enhanced User Experience

Users can now share language-specific URLs (e.g., https://petclinic.com?lang=de), making the app more inclusive and user-friendly.

Lessons for Developers

Design for Global Audiences Early: Baking i18n into your architecture from day one avoids costly refactors later.
Leverage Framework Features: Spring’s LocaleResolver and Thymeleaf’s i18n integration simplify what could otherwise be a complex task.
Prioritize Clean Templates: Keep text out of HTML/CSS/JS—it belongs in resource files.

Community Impact

This commit closes issue #1854, addressing a long-standing request from contributors. By merging this, PetClinic:

Encourages participation from non-English speakers.
Demonstrates Spring’s i18n capabilities as a learning tool.
Sets a precedent for other open-source projects to prioritize accessibility.

Conclusion

Internationalization isn’t just about translating text—it’s about architecting applications to embrace diversity. This update ensures Spring PetClinic remains a modern, inclusive example for developers worldwide.

Check out the full commit here and consider contributing your own translations!

Building a Complex Dungeon Maze Game with Java Swing: An Architectural Deep Dive 🚀

Anuj Ashok Potdar — Sun, 27 Apr 2025 18:26:20 +0000

Java Swing is often overlooked for game development — but when used with good architecture patterns like MVC and TDD, it can be a powerful tool.

In this post, I’ll explain how I built a modular, extensible Dungeon Maze Game using pure Java Swing and share tips for designing maintainable, testable desktop applications.

Why Java Swing for a Game?

Java Swing provides a robust and flexible UI toolkit.

However, it's not a game engine — so to build games with Swing, you have to:

Handle game loops, redraw cycles, and user input manually
Create a clean separation between game logic and UI rendering
Solve challenges related to real-time responsiveness

This made Swing an interesting challenge — and a perfect playground to apply software engineering principles like MVC architecture and Test-Driven Development. Java being a language that I have been using for a while it is easy to learn and apply this framework.

About the Project: Java Swing Dungeon Maze Game

The project is a grid-based dungeon crawler where:

The player navigates caves and tunnels
Encounters obstacles
Solves mazes generated randomly
Moves using keyboard input (Arrow keys)

The game architecture is designed to be extensible, testable, and easy to modify.

You can find the full code here: GitHub Repository

Key Architectural Decisions

🧩 Model-View-Controller (MVC)

Following MVC was critical:

Model: Game logic — player movement, maze generation, obstacles
View: The Swing GamePanel — renders the maze, player, and tiles
Controller: Handles keyboard input and updates the model

Example:

Handling player movement through the GameController:

case KeyEvent.VK_UP -> model.movePlayer(Direction.NORTH);
case KeyEvent.VK_DOWN -> model.movePlayer(Direction.SOUTH);

The GamePanel listens to the controller and updates the visual state accordingly.

One of the unique propositions of this application is that we are updating 2 major views, the top-down view and the first-person view. This concept can be used to create complex game elements like Heads-up-displays, Race Maps, etc.

🧪 Test-Driven Development (TDD)

The project is equipped with JUnit 5 tests covering the core game logic:

Player movement
Maze generation
Tile obstacle placement

Example: Testing if player movement respects walls:

@Test
void testPlayerCannotWalkThroughWalls() {
    Player player = new Player(startLocation);
    Maze maze = new Maze(5, 5);
    assertFalse(player.move(Direction.NORTH, maze)); // Assuming wall exists
}

Having tests made it easy to refactor or add new features without fear of breaking existing logic.

🎲 Randomized Maze Generation

One fun challenge was making the maze always connected but still random. I have used Kruskal's algorithm for the generation of the maze, which ensures generating unique mazes each time, and also that each location is reachable from every location.

To make the game more interesting, it is important to have a certain distance between the finish location and the player's spawn location. This is ensured by BFS, where the player is not "randomly" spawned but rather backtracked from the finish location and placed at n steps away.

I encapsulated random logic inside a dedicated class:

public class RandomGenerator {
    private final Random random = new Random();
    public int nextInt(int bound) {
        return random.nextInt(bound);
    }
}

This makes the randomness easily mockable for unit testing!

🖼️ Swing Graphics Rendering

The GamePanel is where the game world comes alive:

@Override
protected void paintComponent(Graphics g) {
    super.paintComponent(g);
    maze.draw(g, TILE_SIZE);
    player.draw(g, TILE_SIZE);
}

Each game tick:

Clears the panel
Redraws the maze
Redraws the player
Redraws obstacles or items

This manual cycle makes sure the UI stays responsive.

Challenges Faced 💡

Managing real-time updates without a game engine
Designing reusable components while working within Swing's event-driven model
Balancing testability with performance (e.g., avoiding unnecessary redraws)

Each challenge forced me to think like a software engineer, not just a game developer.

How You Can Use This Template

Because the project is built modularly, you can easily extend it:

Add new enemy types
Create different dungeon themes
Add player inventory, health bars, and abilities
Experiment with different maze generation algorithms

Check out the repo if you want to fork and create your own dungeon adventure!

Conclusion 🏁

Building a complex, polished game without a "game engine" using Java Swing was a rewarding experience.

It helped me:

Sharpen my understanding of MVC
Deepen my appreciation for TDD
Create a reusable framework for future Java-based games

If you're looking to solidify your Java skills, I highly recommend trying a Swing-based project yourself!

Feel free to fork Java Swing Dungeon Game and build something amazing. 🚀

Follow me if you want more deep dives into Java development, architecture patterns, and game design! 🙌