When I joined the Insurance Management Platform team, one of my first tasks was to update the policy activation feature — the moment a customer’s insurance officially goes live.
It seemed simple, but activating a policy triggered a complex chain:
<ul>
<li>update the status,</li>
<li>generate certificates,</li>
<li>send notifications,</li>
<li>log payments,</li>
<li>alert reinsurance partners,</li>
<li>update dashboards, and more.</li>
</ul>
The original old design was a single function that called every service in sequence. It worked — until one external API failed.
When the reinsurance service went down, everything after it stopped too. One small outage broke the entire workflow.
Adding retries and conditions only made the system harder to maintain. That’s when I realized the real problem wasn’t the code — it was the coupling.
Policy activation isn’t a procedure; it’s an event. Instead of forcing everything to happen in order, we needed a way for each part of the system to react independently.
That’s where the Publisher/Subscriber (Pub/Sub) model changed everything. Now, the activation service simply publishes a “policy_activated” event.
Other services — notifications, accounting, document generation, analytics — subscribe to it and act on their own.
<img src="https://media.daily.dev/image/upload/s--OgPbUJnc--/f_auto/v1763044717/ugc/content_4bcf4a84-7492-431a-9d08-41bfd06b13aa?_a=BAMAK+ZW0" alt="178e1440-81c6-4792-81a3-c8c4fde2984b">
We used Kafka to handle these event streams. The result was transformative: the system became faster, more resilient, and easier to extend. When a new service needed to react to activations, it could just subscribe — no code changes to the core.
The first live test worked flawlessly. Every part of the system responded instantly, and one failed service no longer broke the rest.
That’s the beauty of Pub/Sub — it turns complexity into collaboration.
One event, many independent reactions, and a system that finally runs itself.
When I embraced event-driven architecture, I stopped firefighting and started building systems that grow gracefully. That’s the quiet power of Pub/Sub.

Anubhav Bhatt

A tightly coupled insurance policy activation system was failing when any downstream service experienced an outage. By refactoring from sequential service calls to an event-driven pub/sub architecture using Kafka, the system became resilient and decoupled. Each service now independently subscribes to policy activation events, allowing failures to be isolated and new services to be added without modifying core logic.

Pub/Sub Model Saved Our Insurance System from Collapse

Interesting. It seems all the processes were independent from each other, so they could be called in parallel instead of sequentially.
Does using Kafka add any fail-over capability to the application?
<blockquote>
One small outage broke the entire workflow.
</blockquote>
I’m not sure the proposed implementation fully resolves that. I would probably use queues for this kind of scenario.
What do you think?
Thanks for sharing.

The concept is still a bit vague for my level. It will be greater if you can give practical samples. Anyway, thanks for sharing &lt;3

Curious, is the incoming number of events high enough that Kafka is needed?

<blockquote>
The original old design was a single function that called every service in sequence. It worked — until one external API failed.
</blockquote>
Sound like it only a 5 minutes work to resolve the problem.

I want the more detailed of this article.