Pravin Durai – Sandhata

The Microservice Hangover

Pravin Durai — Wed, 22 Apr 2026 07:03:42 +0000

The microservices gold rush is over.

Teams that chased the pattern through 2019 and 2022 are now managing systems that take three engineers to debug a single failed transaction, require five teams to coordinate a two-line configuration change, and go down in four places when one database has a bad morning.

The original promise was real: split your application into independent services so each piece can be built, deployed, and scaled without touching anything else. When it works, it is genuinely powerful. When the boundaries are wrong, you do not get the benefits of microservices. You get all of the cost.

In 2026, the most important architectural question in Java shops is no longer “how many services should we build?” It is “do these boundaries actually make sense?”

“The right architecture is the one that matches the actual structure of your organization and your problem. Everything else is decoration.”

The Myth That Started Most of the Trouble

The assumption underneath most over-engineered microservice systems is this: smaller services scale better.

On the surface, the logic sounds reasonable. Less code, fewer responsibilities, simpler deployments. In practice, splitting a system into many small pieces does not make each piece faster. It adds a cost every time those pieces need to communicate. And in any real application, the pieces communicate constantly.

Here is what that looks like in a Java e-commerce system.

A user searches for running shoes. Fifty results come back from the Catalogue service. Each result needs a current price check from the Discount service. The Catalogue service, using Spring Cloud OpenFeign, makes 50 individual HTTP calls, one per product, before it can return the page.

Underneath this, Kubernetes is running, Docker containers are optimized, auto-scaling is configured. The page is still slow. The bottleneck is not computing power. It is the time spent on 50 separate “please respond to me” round-trips across a network. Each one is fast in isolation, 5 to 10 milliseconds. Fifty of them in sequence adds up to a visible delay on every single page load.

Plain English: What is a network round-trip?

Every time one service asks another for information, it sends a request and waits for a reply. That waiting time is called a round-trip. On a local network it might be 2ms. Multiply that by 50 calls and you have added 100ms to every page load before any business logic runs. Users feel this.

The Distributed Monolith: The Worst of Both Worlds

The e-commerce example above has a name: a Distributed Monolith. The services are physically separated, running in different containers on different infrastructure. But they cannot function independently. The Catalogue service is useless without the Discount service. If Discount goes down, the product page breaks. The system behaves like a single application, but with all the operational overhead of a distributed one.

This is the failure mode that is not discussed enough, because it does not look like a failure from the outside. The architecture diagram has all the right boxes and arrows. The Kubernetes cluster is running. Teams feel like they did the modern thing.

The tell is this: if two services must be updated together every time a feature changes, they are not two services. They are one service distributed across two repositories.

“The question is not how small can this be. The question is: if this service went down for four hours, what else would break?”

If the answer is “everything,” the boundary is wrong. Real service independence means a service can go down, recover, and catch up without any other part of the system losing data or failing its users.

Three Ways Java Teams Are Breaking Their Own Systems

1. Everything talks synchronously

Synchronous communication means Service A sends a request to Service B and waits for a reply before doing anything else.

When everything is healthy, this works fine. When Service B is slow or briefly unavailable, Service A is stuck waiting. Every new request to Service A backs up behind the previous one. If Service C also depends on Service B, it backs up too. The failure moves outward until the whole system is unresponsive.

This is how a slow email verification service takes down an order confirmation flow. The Order Service waits for a 200 OK from the Email Service before confirming the order. The Email Service is under load. Orders queue up. Users see errors. Nobody touched the Order Service.

Plain English: What is synchronous vs. asynchronous?

Synchronous is like a phone call. You wait on the line until the other person answers and responds before you do anything else. Asynchronous is like sending a text. You send the message and continue with your day. The reply comes when it comes. In software, asynchronous communication between services means neither side has to wait on the other to keep working.

The fix is to shift operations that do not need an immediate response to asynchronous messaging. Apache Kafka is the standard tool for this in Java ecosystems. Instead of Service A waiting for Service B, Service A drops a message into a Kafka topic and moves on. Service B picks up the message when it is ready.

There is a specific pattern that makes this reliable called the Transactional Outbox.

Plain English: The Transactional Outbox Pattern

When your Order Service saves an order to the database, it also writes a small note to a special ‘outbox’ table in the same save operation. A background process reads that outbox table and publishes the message to Kafka. Because the order and the note are saved together in a single database transaction, if the application crashes mid-process, the note survives. The message still gets sent. No orders fall silently into a gap between ‘saved to database’ and ‘sent to Kafka.’

2. The database is doing work nobody is watching

Spring Data JPA is the most widely used database tool in the Java ecosystem. It generates SQL queries from your code automatically, which saves enormous amounts of development time. It also generates queries you did not intend, at volumes you did not anticipate, if you stop paying attention to what it produces.

The most common problem is the N+1 query.

Plain English: What is an N+1 query?

Imagine you ask a library assistant for a list of 100 books. That is 1 request. Then, for each book, you walk back to the desk and ask separately who the author is. That is 100 more requests. Total: 101 trips to the desk instead of 1. In software, this happens when JPA loads a list of records (say, 100 orders), then makes a separate database call for each record to load the related data (the customer details for each order). One request to your application produces 101 database queries. At low traffic, this is invisible. At scale, it saturates the database connection pool and slows everything that touches the database.

The fix is to tell JPA to load related data in the same query using a JOIN, or to use batch loading. Both are straightforward once you know the problem exists. The challenge is that the problem is invisible unless you are watching the queries.

The rule is simple: every significant query your application runs in production should be reviewed. Enable SQL logging during development. Use tools like P6Spy or Hibernate’s built-in logging to see the actual SQL being sent to the database. If you see repeated queries with a pattern, you have an N+1 problem. Fix it before it reaches production.

3. When something breaks, nobody knows where

A request to a single-application system touches one codebase. When it fails, you look at one log file.

A request to a distributed system might touch eight services before something goes wrong. Which service failed? At what point in the chain? Was it slow, or did it return an error? Which downstream service caused the problem?

Without the right tooling, the answers to these questions require manually correlating timestamps across eight separate log files. This takes hours. In a production incident, hours are expensive.

Plain English: What is distributed tracing?

Every request that enters the system gets a unique tracking number (called a Trace ID) that travels with it through every service it visits. When something fails, you look up that Trace ID and see the complete picture: every service the request touched, how long each step took, and exactly where it broke. It works like a package tracking number, except for your API calls.

The standard for implementing this in 2026 is OpenTelemetry. It is vendor-neutral, widely supported in the Java ecosystem, and integrates with Jaeger, Grafana, Datadog, and most observability platforms.

The non-negotiable rule: if you cannot trace a request through your entire system on your local machine before you deploy, you cannot operate it in production. Observability is an engineering requirement. It should be built before the first service ships, not retrofitted six months later when something breaks in a way nobody understands.

The Decision Framework: When a Separate Service Is Justified

Before splitting anything into its own service, answer these four questions honestly.

Service Boundary Checklist

• Can this component be deployed without coordinating with any other team or codebase?

• Can this component fail completely without taking anything else with it?

• Does this component have a genuinely different scaling requirement than the rest of the system?

• Does a separate team own this, with no shared development dependencies?

If three or four answers are yes, a separate service is appropriate. If two or more answers are no, the service boundary is premature. Build a well-isolated module within your existing codebase instead, and revisit the question when the conditions change.

The Modular Monolith: The Most Underrated Architecture in Java

The industry spent five years treating “monolith” as an insult. In 2026, the teams shipping fastest are building Modular Monoliths, and they are outpacing their microservice-heavy counterparts on delivery speed and system stability.

Plain English: What is a Modular Monolith?

A single application, but with strict internal walls between business domains. The billing code cannot reach directly into inventory code. The order management module cannot call the user management module through a back door. Each module owns its own data, its own logic, and its own interface with the outside world. The boundaries are enforced in code. It deploys as one unit, so there are no network calls between modules, no distributed transaction problems, and no distributed tracing needed just to understand what a single user action did.

When a module grows to the point where it genuinely needs to scale independently or be owned by a fully autonomous team, extracting it into a real service is straightforward, because the boundary was already clean and well-defined.

A Modular Monolith is not a compromise or a step backward. It is the responsible default for any system that has not yet proven it needs the operational complexity of distributed services. The operational complexity of microservices is a cost you should pay only when the benefit justifies it.

“A well-structured Modular Monolith will beat a poorly partitioned microservice system in delivery speed, incident response time, and developer experience. Almost every time.”

Building Resilience Into What You Already Have

Distributed systems have failures. Services go down. Networks slow. Third-party APIs miss their response time commitments. The goal is not to eliminate failures. It is to make sure individual failures do not become system-wide outages.

Resilience4j is the standard Java library for this. It gives you three core tools.

Circuit Breaker

When a downstream service starts failing repeatedly, the circuit breaker stops sending it requests for a set period. Instead of continuously hammering a struggling service and making the failure worse, the system gives it time to recover. Requests during the recovery window get a fallback response.

Plain English: Circuit Breaker

Like a fuse box in your house. When a circuit is overloaded, the fuse trips and cuts the power to that circuit before the wiring catches fire. You fix the problem, reset the fuse, power comes back on. A circuit breaker in software works the same way. When a service is failing, you stop sending it traffic temporarily, let it recover, then gradually let traffic flow again.

Retry with Backoff

Many failures are transient. A service might briefly be unreachable and recover within two seconds. A retry mechanism automatically re-attempts the request a defined number of times, with a pause between each attempt. This handles momentary blips without surfacing an error to the user. The pause between retries (called exponential backoff) prevents the retrying system from overwhelming the recovering service with requests.

Fallback

A fallback defines what the system does when a service is genuinely unavailable. In a user registration flow, if the email verification service is down, a fallback might be: complete the registration in the database, queue the verification email in Kafka for when the service recovers, and return a success response to the user. The user is not blocked. The email goes when the system is healthy again.

These three patterns together represent the minimum viable safety net for any distributed system. None of them are optional once services depend on each other.

The Architecture Audit: Six Questions for Your Next Design Review

Run this before your next technical design session

• Are service boundaries drawn at domain lines, or at ‘it felt too big’ lines?

• Are services communicating synchronously for operations that do not need an immediate response?

• Are you monitoring the actual SQL that JPA generates in production?

• Can you trace a single user request across every service it touches, in under two minutes?

• Do you have circuit breakers on every external service dependency?

• Could your system be reorganized into a well-structured Modular Monolith without losing any meaningful technical capability?

If more than two answers are uncomfortable, the architecture review is overdue. These are not edge-case concerns. Each one represents a category of production incident that is entirely preventable with the right design decision made earlier.

The Principle That Settles Most Architecture Debates

Microservices are a solution to organizational and scaling problems that have already materialized. They are a destination, not a starting point.

The right size for a service is the smallest unit that can be genuinely deployed, owned, and operated independently by a team, for a clear purpose, without negotiating with anyone else. If that definition does not describe what you are building, the service is too small.

Every architectural decision has a carrying cost: the operational complexity you take on and maintain indefinitely. That cost is only worth paying when the capability you gain cannot be achieved any other way.

Build for the actual problem in front of you. The architecture should serve the business, not validate a technical preference.

Is Your Architecture Ready for What’s Next?

We help engineering teams audit their service boundaries, identify operational risk, and build the right foundation for scale.

→ Request an Architecture Review

The post The Microservice Hangover appeared first on Sandhata.

Generic Message Buffering | Camunda 7

Pravin Durai — Tue, 11 Jul 2023 13:49:08 +0000

Imagine multiple messages waiting in a message catch event.

When a single throw event is triggered, the data is processed without any issues. However, if multiple message events are thrown simultaneously, only the first one is successfully processed, while the others fail.

This is because the message catch event is busy handling the first message event.

We recently spotted this issue with Camunda 7’s message catch event.

Unlocking The Solution To This Challenge

Our team of experts fabricated a groundbreaking “Generic Message Buffering” logic, with which we’ve revolutionised the way messages are processed asynchronously, effectively resolving any scenario you may encounter.

Fig. 1.1 unveils the powerful list of message catch events eagerly awaiting the trigger.

Fig1.1

In Figure 2.1, we present the logic for Generic Message Buffering. By sending a POST request, we can activate the BPM process described below. Additionally, we have the ability to specify the retry count and retry delay as request parameters. Once the request is triggered, we conduct a basic validation to ensure all necessary information, such as message name, payload, process instance id, and business key, is present.

If all the required data is available, we proceed to send the message to its destination within the “Message Send Task” depicted in Figure 2.1.

If the message is successfully picked up and processed by the message catch event, we encounter no issues.

Fig2.1

In a situation where the message catch event is already occupied processing another message, throwing our own message will result in failure. This is a common occurrence in real-time scenarios, and it is up to the developers to determine how the flow should be handled in such cases.

In our specific case, the failed message will be caught by the boundary event. The error message will then be examined in detail within the “Read Error Message” process (Fig 2.1).

In the event of an error, we can:

Distinguish between errors that require retry logic.
Determine if it is a business error or a technical error.
Necessitate the involvement of technical experts, if it happens to be a business error

When encountering a retriable error, we make an attempt to retry the operation. The number of retries and the delay between retries is determined by the input request.

Potential Scenarios In Re-try

In the context of re-try logic, there are two potential scenarios to consider:

In one of the re-try attempts, the message can be successfully delivered to the end system.

Fig 3.1

Alternatively, if the maximum number of re-try attempts is reached without success, the message will be marked as an error.

If the maximum re-try attempts have been exceeded and the message still hasn’t been delivered successfully, it will require manual re-processing (see Fig 3.2).

Fig 3.2

Key Advantages

Streamlined Error Handling: By effectively managing busy message catch events, we can significantly mitigate potential errors during data processing.

Efficient Data Re-processing: Our approach allows for a substantial reduction in the amount of data that needs to undergo re-processing.

Versatile Solution: Utilizing the same bpmn models, we can easily adapt and apply them to various similar use cases simply by modifying the message name.

Optimizing Efficiency

In order to optimize efficiency, it is vital that both the target BPM and the message buffering BPM are connected to a centralized database. This will allow for seamless integration and streamlined performance. Maintaining a unified database instance is key to achieving optimal results.

The post Generic Message Buffering | Camunda 7 appeared first on Sandhata.

We are Sandhata: Meet Pravin

Pravin Durai — Thu, 02 Dec 2021 15:34:37 +0000

Based in the UK, Pravin Durai is a consultant with Sandhata. Pravin shares the story of his career journey, his experience as an intern and his thoughts on the future.

How did you get started working in IT?

I have been working in IT for 5 years now, and have been with Sandhata Technologies for the past 1.5 years. My career as a software engineer started with Accenture (in Bangalore, India) in 2016 as a Performance Engineer and then I moved to a Developer role.

In these past 5 years I have worked on various project as a performance engineer and developer. Working in many different roles has given me exposure and helped me to understand the complete SDLC.

Recently I have completed a Masters in Computer Science with Industrial Placement.

Why did you decide to pursue a Masters?

I have always wanted to do a post grad degree, and I was inspired by my cousin who did his Masters in the US. But after my graduation, my parents wanted me to work so I started my career as a software engineer. However, I never gave up on my dream of pursuing a Masters. After working for around 3 years I started preparing for the Masters exams at the Queen Mary University of London.

Why did you choose to do a Masters course with an industrial placement year?

The primary objective of doing a Masters is to get an opportunity to learn and to work on some niche and cutting edge skills. I thought the addition of an Industrial Experience year would be a perfect opportunity to test my knowledge gained during my Masters. Also, I was certain that this would increase the odds of me getting a job offer in the UK.

What was the most useful or interesting thing you learnt in your Masters?

During my Masters we were given assignments for each module. Back in India during my undergrad almost all my assignments were theoretical. But on this Masters course it’s the complete opposite and I really liked that. Concrete, real-life projects helped me to understand things in a much better way.

How did you hear about Sandhata?

My Masters dissertation was on the subject of “Cloud Computing”. During my Masters, my professor wanted me to showcase my project to an actual IT company and get feedback. I had been following Sandhata Technologies on LinkedIn for a while and thought they would be a good choice to help me out with this since they have expertise and experience in delivering cloud migration projects for clients. So I approached Sandhata via LinkedIn and they were quite happy to support me.

How did you find your intern role at Sandhata?

I was interacting with Kumar [one of the Sandhata management team] to get feedback on my dissertation and he mentioned about an interesting project where they have an application in .Net and they were looking for someone to convert that into a Java based application. Since I had already worked on similar technology in my previous role, without a second thought I asked if I could work on this project. This is where my journey with Sandhata began.

“I am lucky that I have got the opportunity to work on many different technologies in a short period of time which has broadened my knowledge and experience.”

Please share a bit about what you did on your internship.

During my internship, I worked on a couple of projects: one for one of our clients, Vodafone UK, and the other one was an inhouse project. I particularly enjoyed my first project as I was lucky to work with some very bright people within Sandhata, from whom I learnt a lot.

How did you find joining Sandhata during the COVID pandemic?

Although I started my graduate role during COVID pandemic, the onboarding process was quite smooth. I received my laptop and new joiners kit much quicker than I expected and was supported the whole way. People within Sandhata are very friendly and helped me a lot to setup everything, guiding me whenever I got stuck with any issues.

Now you have moved from an intern role to a permanent role. How are you finding it?

Since I have joined Sandhata, I have always kept my eyes open, looking for any new opportunity. When I moved to a permanent role, one opportunity that I got is to work on the GCAT application. This was a great project for me as there was a big learning curve on new skills and I gave lots of demos to the client, quickly becoming confident and managing to answer their questions thoroughly. The project was delivered on time and the client was very happy with it, which has helped me to prove that I am a strong resource in the team.

What is next for you, Pravin?

I see there are lots of interesting areas e.g. DevOps, Pega, Salesforce within Sandhata which I haven’t worked on so far. I would like to work in these areas to broaden my experience and grow my skillset.

My journey with Sandhata Technologies is just getting started…

Learn More

If you are interested in joining Sandhata, check out our careers page for the latest job openings and how to contact us.

The post We are Sandhata: Meet Pravin appeared first on Sandhata.