Vidulividuli

The Problem That Almost Broke Our Infrastructure

A hidden TLS conflict broke our infrastructure. Here’s how PostgreSQL replication and service mesh mTLS clashed, and what fixed it.

By Avin Kavish
EngineeringFounder Insights
Background
The Problem That Almost Broke Our Infrastructure

There was a point while building Viduli where I thought the system might not actually work.

PostgreSQL replication kept failing. Not intermittently, but consistently. Every attempt to get a primary and replica talking to each other would break with the same vague error: unrecognized SSL handshake.

On the surface, everything looked correct. The database was configured properly. The replication service was set up. Individually, both sides worked. But together, they refused to communicate.

That’s when it became clear this wasn’t a simple bug.


The Problem Wasn’t PostgreSQL

At first, I treated it like a database issue.

I dug through PostgreSQL logs. Then the replication service logs. Then both, side by side, trying to correlate what was happening during connection attempts.

I didn't find anything obvious.

The failure wasn’t happening in one place, it was happening between the two systems.

And that’s where things got harder.


When Security Layers Collide

Viduli is built around a service mesh that enforces secure communication between services using mTLS.

At the same time, PostgreSQL replication also supports (and expects) TLS.

Individually, both systems were doing the right thing:

  • The mesh was encrypting service-to-service traffic
  • PostgreSQL was trying to establish a secure replication channel

But together, they created a conflict.

The mesh was already encrypting traffic. PostgreSQL then attempted to layer its own TLS on top of that.

Two encryption layers. Two expectations. One broken handshake.

The result:

  • Connections failing silently
  • Handshake errors with no clear root cause
  • Hours of debugging across multiple layers

The Wrong Assumption

The assumption I made early on was simple:

If both systems use TLS, they should work together.

That assumption was wrong.

Security systems don’t compose cleanly by default. Especially when they operate at different layers of the stack.

Instead of reinforcing each other, they were interfered.


The Turning Point

The solution wasn’t to remove security.

It was to be more precise about where and how it was applied.

Replication traffic needed to be treated differently.

Instead of forcing all traffic through mesh-level mTLS, I made targeted configuration changes that allowed PostgreSQL replication to establish its own TLS connection without the mesh re-encrypting it.

Not globally. Not as a shortcut.

But surgically - affecting only the specific services that required it.

Everything else remained secured by the mesh.


Viduli Cloud

Viduli Cloud is a platform that makes it easy to deploy and manage your apps, databases, and caches.

Why Shortcuts Would Have Failed

There were easier ways out.

I could have:

  • Disabled TLS for replication
  • Turned off mesh security entirely
  • Forced everything into a simpler but less secure setup

All of those would have made the system “work.”

But they would have broken something more important.

Security. Consistency. And ultimately, scalability.

If the system only works when you weaken it, it doesn’t work.


The Part No One Talks About

This is the part of building infrastructure that doesn’t show up in demos.

There were long stretches where nothing moved forward.

Just logs. Failures. Small tweaks. More failures.

No feedback. No validation. Just trying to make a system behave correctly across layers that weren’t designed to cooperate out of the box.

This is where most of the real work happens.


What This Enabled

Solving this problem wasn’t just about fixing replication.

It shaped how the platform works today.

Viduli provides secure service-to-service communication by default using mTLS, without requiring developers to understand or configure it.

At the same time, it avoids breaking underlying protocols that depend on their own communication patterns.

Because the goal isn’t just to add security, it’s to make it transparent to our users.


The Real Lesson

Building systems like this forces a simple realization:

You can’t fake the foundation.

If something doesn’t work properly at the core, it will fail later, and it will fail in ways that are harder to debug, more expensive to fix, and impossible to scale.

That’s why shortcuts don’t pay off.

Not in infrastructure.


Closing

Viduli exists to remove the complexity of cloud infrastructure so developers can focus on building.

To get there, we had to go through that complexity ourselves and solve it properly.

That’s the part users never see.

And that’s precisely the point of Viduli - we solve problems so you don't have to.

Switch to Viduli now and skip the future hassle: Sign Up

Join our newsletter

Get the latest updates and insights delivered to your inbox.