<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Microservices on Shaaf's blog</title><link>https://shaaf.dev/tags/microservices/</link><description>Recent content in Microservices on Shaaf's blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 01 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://shaaf.dev/tags/microservices/index.xml" rel="self" type="application/rss+xml"/><item><title>Decomposing a Monolith into Microservices with Call Graph Analysis</title><link>https://shaaf.dev/post/decomposing-a-monolith-into-microservices-with-call-graph-analysis/</link><pubDate>Tue, 01 Sep 2026 00:00:00 +0000</pubDate><guid>https://shaaf.dev/post/decomposing-a-monolith-into-microservices-with-call-graph-analysis/</guid><description>&lt;h1 id="decomposing-a-monolith-into-microservices-with-call-graph-analysis">Decomposing a Monolith into Microservices with Call Graph Analysis&lt;/h1>
&lt;p>Splitting a monolith into microservices is a problem of finding boundaries. The
wrong boundaries produce distributed monoliths &amp;ndash; microservices that cannot be
deployed independently because they call each other synchronously for every
operation. The right boundaries follow natural seams in the code: clusters of
functions that are tightly coupled internally but loosely connected to the rest
of the system. This post picks up the CoolStore monolith from
&lt;a href="https://shaaf.dev/post/migrating-coolstore-monolith-to-quarkus-with-rgctl/">migrating it to Quarkus with rgctl&lt;/a>
and applies the same graph analysis to the next question: where to cut it into
services.&lt;/p></description></item></channel></rss>