<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Monoliths on biancarosa.com.br</title><link>/tags/monoliths/</link><description>Recent content in Monoliths on biancarosa.com.br</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 26 Jan 2026 16:22:57 +0000</lastBuildDate><atom:link href="/tags/monoliths/index.xml" rel="self" type="application/rss+xml"/><item><title>Database Design for Modular Monoliths: Avoiding the Coupling Trap</title><link>/posts/database-design-for-modular-monoliths/</link><pubDate>Mon, 26 Jan 2026 16:22:57 +0000</pubDate><guid>/posts/database-design-for-modular-monoliths/</guid><description>&lt;p>&lt;em>This post was originally published on my &lt;a href="https://backendengineeringadventures.substack.com/p/database-design-for-modular-monoliths">Substack - Backend Engineering Adventures&lt;/a>.&lt;/em>&lt;/p>
&lt;p>Last week, we covered deployment patterns - how to run multiple services from the same codebase. But here’s the thing: you can have perfectly separated Docker containers and still end up with a nightmare when it’s time to extract a module. Why? The database.&lt;/p>
&lt;p>This is where most modular monoliths, migration to microservices or service extraction fails. What starts with &lt;code>JOIN payments.transactions ON orders.payment_id = payments.id&lt;/code> ends up becoming the coupling hell - suddenly extracting the payments module requires untangling months of accumulated database coupling.&lt;/p></description></item></channel></rss>