Modular Monolith vs Microservices: A Practical Architecture Guide

Software architecture trends often swing like a pendulum. Over the past decade, microservices dominated the conversation, promising scalability, autonomy, and faster delivery. Today, many teams are re-evaluating that choice and rediscovering a more balanced approach: the modular monolith.

This article explores why microservices became the default, where they struggled, and why modular monolithic architecture is emerging as a pragmatic alternative for many teams.

TL;DR: Modular Monolith vs Microservices

Microservices can enable independent scaling and deployments, but they also introduce distributed-system complexity that many teams don’t need. A modular monolith is often a better fit for small to medium teams because it keeps strong domain boundaries inside a single deployable application.

• Microservices work best for large organizations with high operational maturity and autonomous teams.
• Modular monolith architecture provides clear module boundaries without network calls between domains.
• If your main challenge is delivery speed, maintainability, and cost, a modular monolith is often the pragmatic default.
• You can still evolve: well-designed modules can be extracted into microservices later if scale demands it.

Who This Article Is For

This guide is designed for software teams and engineering leaders who are evaluating modern application architecture and want to avoid unnecessary complexity.

• Startup and SaaS teams deciding between microservices and monolithic architectures
• Small to medium engineering teams struggling with microservices operational overhead
• Technical leads planning long-term scalable system design
• Organizations considering a transition from microservices back to a modular monolith
• Developers looking for a practical, maintainable architecture approach

Why Microservices Became the Default Choice

For nearly a decade, microservices were seen as the natural evolution of software architecture. As systems grew and teams expanded, breaking applications into smaller services promised independent deployments, better scalability, and faster delivery.

Microservices also became a signal of technical maturity. Organizations associated them with industry leaders and modern engineering practices, often adopting them early to avoid future rework.

For a time, this approach appeared inevitable. Splitting systems felt like progress.

Common Myths About Microservices

Microservices are often presented as a universal solution for modern software systems. In reality, many assumptions around them are misleading.

• Myth: Microservices automatically improve scalability.
  In practice, many applications scale uniformly, meaning the entire system grows together. Microservices only provide real benefits when different components have significantly different scaling requirements.
• Myth: Microservices speed up development for all teams.
  While they can help large autonomous teams, smaller teams often experience slower delivery due to increased coordination, infrastructure setup, and deployment pipelines.
• Myth: Monoliths are inherently outdated.
  A well-structured modular monolith follows modern design principles and can be just as maintainable and scalable as distributed systems - without unnecessary complexity.
• Myth: You must start with microservices to scale later.
  Starting with a modular monolith often provides a cleaner and safer path to microservices when real scaling needs emerge.

Why Microservices Struggle Outside Their Intended Context?

Microservices were designed for a very specific environment: large systems, autonomous teams, and high operational maturity.

Most teams, however, do not operate under these conditions.

In practice, microservices shifted complexity away from code and into infrastructure. Simple changes began to require coordination across multiple services, pipelines, and teams. Deployments slowed, debugging became distributed, and observability turned into a requirement rather than a nice-to-have. Infrastructure costs increased even when scale did not.

Microservices didn't fail as an idea. They struggle when applied outside the context they were designed for creating unnecessary complexity without delivering their intended benefits.

A Real-World Scenario: When Microservices Became a Bottleneck

Consider a growing SaaS product with a small engineering team of six developers. To follow modern best practices, the team adopted a microservices architecture early in the product lifecycle.

Within a year, the system consisted of more than ten services, each with its own deployment pipeline, monitoring setup, and infrastructure configuration. Simple feature changes required updates across multiple services and coordination between developers.

Instead of moving faster, the team spent increasing time managing CI/CD pipelines, debugging distributed failures, and maintaining cloud resources. Infrastructure costs rose, while feature delivery slowed.

After consolidating the system into a modular monolith with clearly defined internal modules, the team reduced operational overhead, simplified deployments, and improved development speed - while still maintaining strong domain separation.

This pattern is increasingly common across startups and small to medium engineering teams.

What is a Modular Monolith?

A modular monolith structures a single application as a collection of internally isolated modules, each aligned with a specific business or functional domain. Instead of allowing unrestricted access across the codebase, modules interact only through explicit contracts, ensuring that related functionality stays together and unrelated concerns remain separated. This intentional structure reduces accidental coupling and leads to a system that is more cohesive, predictable, and resilient to change.

Key Characteristics of a Modular Monolith

A modular monolith is defined not just by its structure, but by the architectural rules it enforces.

• Single runtime and deployment unit
• Internally isolated, domain-aligned modules
• Explicit APIs between modules
• No direct data access across module boundaries - modules access other modules' data only through explicit APIs, never directly querying each other's tables
• No network calls between domains
• Clear ownership and responsibility per module

These characteristics provide service-like boundaries while keeping execution in-process.

Architecture Comparison

Aspect	Monolith	Modular Monolith	Microservices
Structure	Tightly coupled codebase	Single codebase with strict modules	Multiple independent services
Deployment	Single	Single	Multiple
Communication	In-process	In-process via module APIs	Network calls
Data ownership	Shared database, no boundaries	Single database, logical boundaries per module	Database per service
CI/CD complexity	Low	Low	High
Operational overhead	Low	Low–Medium	Very high
Debugging	Simple early	Predictable	Complex (distributed)
Scalability	Whole app (vertical/horizontal)	Whole app (vertical/horizontal)	Independent per service
Best fit for	Very small teams	Small–medium teams	Large organizations

Benefits of Modular Monolithic Architecture

When implemented correctly, modular monolithic architecture offers practical advantages across development, operations, and cost.

• Strong modular boundaries: Clear separation of domains prevents tight coupling while keeping related logic together.
• ACID transactions across modules: Cross-module operations can use native database transactions, avoiding the complexity of distributed transaction patterns like sagas or two-phase commit required in microservices.
• Simple deployment and operations: Single build, deploy, and rollback without distributed-system overhead.
• Lower complexity, easier debugging: In-process communication enables predictable behavior and straightforward troubleshooting.
• Faster development and CI/CD: Fewer pipelines and dependencies improve delivery speed and reliability.
• Future-ready architecture: Well-defined modules can be extracted into microservices when scale or team size demands it.

Challenges of Modular Monolithic Architecture

Despite its advantages, a modular monolith is not without trade-offs.

• Requires strong discipline: Without strict enforcement of module boundaries, it can degrade into a tightly coupled system.
• Limited independent scalability: The entire application scales as a unit, though horizontal scaling across multiple instances is fully supported.
• Shared deployment risk: A bug in one module can impact the whole system.
• Growing codebase over time: Can become harder to navigate without structure.
• Boundary enforcement needs tooling: Requires architectural rules and automated checks.

When to Use Modular Monolithic Architecture

Modular monolithic architecture is most effective in the following scenarios.

• Small to medium-sized teams: Need simplicity with domain separation.
• Early to mid-stage products: Flexibility matters more than fine-grained scalability.
• Limited operational maturity: Avoid distributed overhead.
• Uniform scaling needs: Most components scale together.
• Systems expected to evolve: Clean path to microservices later.

Frequently Asked Questions (FAQ)

Is a modular monolith better than microservices?

A modular monolith is often better for small to medium-sized teams because it reduces operational complexity while maintaining strong architectural boundaries. Microservices are more suitable for large organizations with high scalability and operational maturity.

Can a modular monolith scale?

Yes. A modular monolith can scale effectively by scaling the entire application. In many real-world systems, most components scale together, making this approach sufficient and simpler than distributed microservices.

When should you choose microservices?

Microservices make sense when different parts of the system require independent scaling, when teams are large and autonomous, and when the organization can handle distributed system complexity.

Is starting with a monolith a bad practice?

No. Starting with a well-structured modular monolith is considered a best practice by many experienced architects. It provides simplicity early on and allows clean evolution into microservices when needed.

How is a modular monolith different from a traditional monolith?

A traditional monolith often lacks clear boundaries and becomes tightly coupled over time. A modular monolith enforces strict module separation, explicit APIs, and domain ownership while remaining a single deployable application.

Final Thoughts

Microservices are not obsolete - but they are no longer the default answer for every system.

For many teams, the real challenge is not scale. It is clarity, ownership, and operational simplicity.

Modular monolithic architecture offers a pragmatic middle ground: strong internal boundaries without unnecessary distributed system complexity.

If you have any questions or need help with CI/CD pipelines, DevOps automation, or cloud solutions, feel free to reach out to our team here.

Power Automate Silent Failures: Why Flows Succeed But Don’t Work (And How to Fix Them)

Introduction

Power Automate is a powerful automation tool. But sometimes, it behaves in a confusing way.

A flow may smile, report Succeeded, and quietly do not do the thing you need.

No errors. No alerts. Just an automation–shaped hole where your business logic should be.

These are called silent failures, and they are some of the most dangerous problems in low-code automation.

In this blog, we will understand:

• What silent failures are
• Why they happen
• How to detect and prevent them

What is a Silent Failure?

A silent failure happens when:

• The flow run status is Succeeded.
• No error message is shown
• But the expected outcome never happens.

For example:

• A condition evaluates incorrectly and skips critical steps
• An action runs but affects zero records
• An API call returns an empty response without error
• A loop runs zero times without warning.

Power automate assumes you meant to do that. You did not.

Common Causes of Silent Failures

1. Conditions That Evaluate the “Wrong” Way

Conditions are the most common cause of silent failures.

Common mistakes:

• Comparing a string with a number
• Checking for null instead of an empty string
• Assuming “Yes” equals true
• Case sensitivity issues

Because of this, the flow goes into the wrong branch and skips important actions.

2. Empty Arrays and Zero-Iteration Loops

Actions like

• Get items
• List rows
• Get emails

Can return zero records without any error.

If you use Apply to each, the loop simply does not run.

No errors. No warnings.

3. Actions That Succeed but Do Nothing

Some connectors report success even when nothing changes.

Example:

• Updating an item with the ID is wrong.
• Deleting a record that doesn’t exist
• Sending an email with an empty “To” field resolved at runtime.

The action succeeds, but the result is missing.

4. Misconfigured Run After Settings

Run after is powerful but risky.

If you configure:

• Run after has failed
• Run after is skipped

But forget:

• Run after has timed out

Then your error handling logic may never run.

5. Expressions That Return Null Silently

Expressions fail quietly when:

• A property does not exist
• JSON paths are wrong
• Dynamic content is missing

Power Automate does not throw an error. It simply continues.

How to Catch Silent Failures

1. Validate Data Before Processing

Before doing anything important, verify assumptions.

Examples:

• Check array length is greater than zero
• Confirm required fields are not empty
• Validate IDs and key exist
• Use Conditions like: Length(body('Get_items')?['value']) > 0

If the condition fails, terminate the flow intentionally.

2. Use Terminate Actions Strategically

The Terminate action is very useful.

Use it to:

• Stop the flow when preconditions are not met
• Mark runs as Failed or Cancelled intentionally
• Surface logic error early

A failed flow is easier to identify than a silent one.

3. Log What You Expect, Not Just What You Get

Use:

• Compose
• Append to string variable

Log details such as:

• Number of records retrieved
• Which condition branch was executed
• Important variable values

This makes troubleshooting easier.

4. Build a Dedicated Error Handling Scope

Wrap critical actions inside scopes:

• Main logic
• Error handler

Configure Error Handler to run after:

• Has failed
• Has timed out
• Is skipped

Inside Error Handler:

• Send an email or Teams notification
• Log the run ID
• Capture error details

5. Verify Output After Important Actions

After key actions, verify results:

• After Update item, check returned ID
• After Create record, confirm required fields exist
• After Send email, verify Message ID is not null

If verification fails, terminate the flow.

6. Add “This Should Never Happen” Branches

In conditions:

• Add an else branch for unexpected values
• Treat unknown states as errors, not defaults

Silence helps bug hide. Logging exposes them.

Best Practice Tips:

Think of Power Automate as a very literal assistant

It will:

• Do exactly what you tell it
• Assume success unless told otherwise
• Avoid raising errors unless forced

Your job is to:

• Question assumptions
• Validate results
• Make failures visible

Frequently Asked Questions

Why does my Power Automate flow show Succeeded but not work?

This usually happens due to silent failures such as incorrect conditions, empty data returned from actions, skipped loops, or expressions resolving to null without throwing errors.

What is a silent failure in Power Automate?

A silent failure occurs when a flow completes successfully but does not perform the intended action, and no error message is displayed.

How can I detect silent failures in Power Automate?

You can detect silent failures by validating inputs, logging expected outputs, using terminate actions, and implementing proper error handling scopes.

Do empty arrays cause Power Automate flows to skip actions?

Yes. If an action like Get items returns zero records, loops such as Apply to each will not run, and no warning will be shown.

Is error handling important in Power Automate?

Yes. Proper error handling ensures issues are surfaced instead of silently ignored, making flows easier to monitor and debug.

Final Thought

Silent failures are not Power Automate bugs.

They are missing conversations between you and your flow.

Make your flows

• Chatty
• Opinions.
• Loud when something goes wrong

Green checkmarks feel good, but the truth is better.

A noisy failure is better than a silent success.

If you have any questions you can reach out our SharePoint & Power Automate Consulting team here .

How to Filter SharePoint Online News Posts in Communication Sites (Step-by-Step Guide)

Introduction

SharePoint Online's News feature has become an essential tool for internal communications, helping organizations share updates, announcements, and stories across their workforce. However, as your news content grows, a common challenge emerges: how do you keep everything organized and ensure employees see only the most relevant information?

Imagine your communication site displaying a mix of company-wide announcements, departmental updates, project reports, and blog posts all in one feed. While comprehensive, this approach can overwhelm users and make it difficult to find specific types of content. Department heads want to see only their team's updates, project managers need quick access to status reports, and employees looking for blog content don't want to scroll through unrelated announcements.

The solution is to filter your News web part by category. By organizing your news posts into distinct types such as:

• Blogs
• Departmental updates
• Project news
• Company announcements
• Status reports

You can create targeted news sections that display exactly what your audience needs to see.

In this guide, we'll show you how to filter SharePoint News using the Page Category field—a fully Microsoft-supported method that leverages page properties. This approach requires no custom development, works across multiple sites, and gives you complete control over how news content is organized and displayed throughout your SharePoint environment.

Why Use SharePoint Online to Filter News?

You benefit from filtering:

• Show only relevant News posts.
• Organize content by categories.
• Create sections for your blog.
• Maintain a clean communication site.
• Improve information discoverability.

You may filter News on any page by using information like Page Category.

Requirements

Before you begin, ensure you have:

• A SharePoint communication site
• Site owner or administrator permissions
• Permission to modify the Site Pages library
• At least a few news posts already created (for testing the filter)

Step 1: Establish a Page Category Column in the Site Pages Library

1. Navigate to your Communication Site.
2. Select Site contents.
3. Access Site Pages, hover over it to see visible ellipses, then click on it to see “Setting.”

4. Click Create column and select Choice as the type.
5. Label the column as "Page Category".
6. Add choice values such as:
   • Blog
   • Project Report
   • Status Report
   • General News
   • General Page
   • Announcement
   • News
7. If you want to set a default value, select one; otherwise, leave it blank.
8. Click the "OK" button to create the column.

Important: this column should be established within the Site Pages library – not within any other list or library.

Step 2: Categorize Your News Posts using Page Category

Every News post needs to have a category assigned for filtering purposes.

1. Open any News Post.
2. Select Page details (located at the top-right).
3. Scroll down to page category.
4. Pick a value (for instance, blog).
5. Save your changes (the page will auto-save) or republish if already published.

Step 3: Add the SharePoint News Web Part to Your Page

Navigate to the page where you wish to show filtered News.

1. Select Edit.
2. Click on the plus sign.
3. Search for News.
4. Integrate the News web part.
5. Choose your preferred format (tiles, list, carousel, etc.).

Note: If you have already been on your communication site, then skip the few steps.

Step 4: Apply Filters to the News Web Part Based on Page Category

1. Modify your page.
2. Highlight the News web part.
3. Select the Edit web part option (pencil symbol).

4. Scroll down to Filter.
5. Pick Page properties.

6. In the Property name section, choose: Page category.

7. In the value input field, type or select: Blog.

8. Implement changes.
9. Publish the page.

Now, the News web part will exclusively show entries labeled as “blogs.”

Step 5: Create a Blog Section Utilizing News Filtering (optional)

You can establish a specific blog page by using this filtered News web part.

Example Configuration:

• Page category = Blog

The news web part was adjusted to display solely blog entries.

Unique banner, design, and navigation links.

This provides a comprehensive blog experience within SharePoint Online.

Step 6: Scale Across Multiple Sites (Reusing the Page Category Column)

Once you've successfully set up filtered news on one communication site, you'll likely want to implement the same categorization system across other sites in your organization. The good news: you don't need to recreate the Page Category column from scratch each time.

SharePoint allows you to convert your custom column into a reusable Site Column that can be added to any communication site. This ensures consistency in how news is categorized across your entire SharePoint environment and saves significant setup time.

Benefits of Using Site Columns

• Maintain consistent categorization across all sites
• Save time by avoiding repetitive column creation
• Ensure all sites use the same category values
• Make updates to categories in one place

How to Create and Reuse the Page Category Site Column

Part A: Convert to Site Column (on your original site)

1. Navigate to Site Settings on your source communication site.
2. Under Web Designer Galleries, select Site columns.
3. Click Create.
4. Enter the column name: Page Category.
5. Select type: Choice.
6. Add your choice values (Blog, Announcement, Project News, etc.).
7. Choose an appropriate group or create a new one (e.g., "Custom News Columns").
8. Click OK to save.

Part B: Add Site Column to Other Sites

1. Navigate to the target communication site where you want to use filtering.
2. Go to Site contents.
3. Open Site Pages library settings.
4. Click Add from existing site columns.
5. Locate and select Page Category from the appropriate group.
6. Click Add, then OK.

The Page Category column is now available on the new site with all the same options you configured originally. You can immediately begin categorizing news posts and setting up filtered News web parts following Steps 2-4 from this guide.

Pro Tip: If you need to add new category values later, update the Site Column definition, and the changes will be reflected across all sites using that column.

Frequently Asked Questions (FAQs)

Can I filter SharePoint Online News by category?

Yes, you can filter SharePoint Online News by creating a Page Category column in the Site Pages library and applying it as a filter in the News web part.

What is the Page Category column in SharePoint?

The Page Category column is a custom metadata field added to the Site Pages library that helps categorize news posts such as blogs, announcements, and project updates.

Is filtering SharePoint News using Page Properties supported by Microsoft?

Yes, using Page Properties like Page Category for filtering the News web part is fully supported by Microsoft in SharePoint Online.

Can I reuse the Page Category column across multiple SharePoint sites?

Yes, by creating a Site Column, you can reuse the Page Category column across different communication sites for consistent filtering.

Can I create a blog section in SharePoint using the News web part?

Yes, by filtering the News web part with Page Category set to “Blog,” you can create a dedicated blog section within SharePoint Online.

Does filtering affect existing news posts?

No, existing news posts will appear once you assign them a Page Category value.

Conclusion

Filtering SharePoint Online News using the Page Category column is a powerful yet simple way to organize content and deliver targeted updates to users. By leveraging page properties and the News web part’s built-in filtering capabilities, organizations can create structured blog sections, department-specific news areas, and cleaner communication sites.

This approach is fully supported by Microsoft, scalable across multiple sites, and improves content discoverability without requiring custom development.

With proper categorization in place, SharePoint News becomes a more effective communication tool for your organization.

If you have any questions you can reach out our SharePoint Consulting team here.