Enterprise software used to be simple. You built one big application. Everyone knew where everything lived. All the code sat in one repository. Deployments meant shipping the entire thing. But modern commerce moves too fast for monoliths.

Companies today need to iterate quickly. They need to scale individual pieces of their platform independently. They need to swap out components without touching the rest of their system. They need teams that can work on different parts without stepping on each other. Monolithic architecture fights against all of these needs.

At Broadleaf, we took a different path early on. Instead of cramming everything into one massive codebase, we split our platform into over 30 independent services. Each one handles a specific piece of the commerce puzzle. We call these bounded contexts because each service owns a clear boundary of business functionality.

Why does any of this matter to you? Because when you're building commerce experiences, you need speed and flexibility above everything else. You need to swap out parts when requirements change. You need to scale individual components when traffic spikes. You need to adapt quickly to new business needs. Monoliths simply can't deliver on these requirements.

Understanding our architecture means grasping four distinct service types and how they work together to create flexible commerce solutions. Let me walk you through each tier.

The Four Tiers That Power Everything

Resource Services: Your Single Source of Truth

Resource services own data. That's their primary job, and they take it seriously. The Catalog service knows everything about your products and SKUs. The Pricing service handles all your dynamic and set prices, including sales pricing and contract pricing. The Offer microservice is responsible for promotions, such as BOGO (Buy One, Get One) rules and discount codes. The Inventory service tracks what's available, what's backordered, and what's out of stock.

These services talk directly to databases. They handle persistence, validation, and all the complex business rules around their specific domain. When you log into the Broadleaf admin and update a product description, you're hitting the Catalog service directly. When you change a price, you're talking straight to the Pricing service. When you create a new promotion, you're interacting with the Offer microservice. When inventory levels change, the Inventory service handles the update.

The beauty of resource services lies in their focused responsibility. Clean separation means no confusion about who owns what data. No duplicate logic scattered across multiple codebases. No wondering which service has the "real" version of your product information.

Because resource services are domain-focused, they're perfect for direct data management operations. Administrative users work with them directly. The services expose rich APIs that handle all the complexity of their specific business domain. Want to create a complex product bundle? The Catalog service handles that. Need sophisticated pricing rules based on customer segments? The Pricing service manages those calculations.

Orchestration Services: The Smart Coordinators

Here's where things get more interesting. Your customers don't think about service boundaries. They don't care that product information lives in one service while pricing lives in another. They want to see a product page with the right price, current inventory levels, applicable promotions, and maybe some related product recommendations. That's data from four or five different resource services.

Making separate API calls from your front-end would be a performance disaster. Imagine a product listing page that displays 24 products. Without orchestration, that could mean 100+ individual API calls just to render one page. Network latency would kill your page load times.

Orchestration services solve this by acting as intelligent coordinators. The Catalog Browse service calls out to Catalog, Pricing, Inventory, and Offer services, then combines everything into one comprehensive response. Your front-end makes one API call instead of dozens. Your page loads in milliseconds instead of seconds.

But orchestration goes deeper than just data aggregation. Take checkout flows as an example, when someone clicks "Place Order," dozens of complex operations need to happen in the right sequence. Cart validation against the current inventory. Tax calculation based on shipping address. Shipping rate lookup from third-party providers. Payment processing through your gateway. Order creation across multiple systems. Inventory reservation to prevent overselling.

The Cart Operations orchestration service handles this entire workflow. One API call from your front-end triggers a sophisticated cascade of operations across multiple services and external systems. If any step fails, the orchestration service handles rollback and error recovery. Your front-end gets a simple success or failure response, while the orchestration layer manages all the complexity.

Orchestration services typically don't maintain their own persistent data stores. Their job is coordination, not storage. They're stateless by design, which makes them easy to scale horizontally when traffic increases.

Admin Services: The Management Layer

Admin services power your back-office tools and business user interfaces. They're not handling core commerce logic like calculating prices or managing inventory. Instead, they provide the specialized interfaces and utilities your business users need to manage the underlying resource services effectively.

These services handle everything from the metadata that drives admin form layouts to bulk import utilities that let merchandisers update thousands of products at once. They manage scheduled jobs that sync data with external systems. They provide the workflow tools that route approvals through your organization's hierarchy.

Admin services translate between the raw power of resource services and the user-friendly interfaces your business teams need. A merchandiser doesn't want to construct complex API calls to update product information. They want intuitive forms, bulk editing capabilities, and rich media management tools.

The admin layer also handles specialized business workflows that don't fit cleanly into any single resource service. Product approval workflows might touch Catalog, Pricing, and Inventory services. Campaign management might coordinate between Offer, Customer, and Analytics services. Admin services orchestrate these cross-cutting business processes.

Utility Services: The Foundation Everything Depends On

Sometimes, there is functionality that needs to be shared across services, and duplication of this functionality becomes impractical and difficult to manage. Examples of this include Authentication and Authorization, Configuration Management, API Routing and Filtering, and Service Discovery and Health Monitoring. Instead of building these capabilities into each service individually, we centralized them into dedicated utility services.

Utility services handle the cross-cutting concerns that make microservices architectures actually work in production. Without them, you'd have 30+ services each implementing their own security, each managing their own configuration, each trying to figure out how to talk to each other. That's a recipe for inconsistency and operational nightmares.

These utility services provide the foundational infrastructure that allows the microservices to function in a cohesive and standardized manner.  Developers building on resource services don't need to worry about OAuth token validation or configuration file management. Instead, they can keep their focus on business logic while the utility layer handles the technical plumbing.

How Different Users Experience the Platform

The architecture really shows its strengths when you compare how different types of users interact with the system. Each user type gets an experience optimized for their specific needs.

Administrative Users and Direct Service Interaction

Merchandisers, pricing analysts, and inventory managers work directly with resource services through the admin interface. Need to update a product description? The admin interface routes that request straight to the Catalog service. Want to create a new pricing rule? You're working directly with the Pricing service's APIs.

The admin interface acts as a sophisticated client for the resource services, but the underlying API interaction is direct and unmediated. No extra layers. No unnecessary abstraction. Administrative users get the full power of each service's domain-specific functionality.

The admin experience is optimized for data management efficiency. Bulk operations, complex queries, detailed validation feedback, and rich editing interfaces all come from this direct connection to resource services. When you're managing thousands of products or complex pricing structures, you need that direct access to the service's full capabilities.

Customer-Facing Experiences and Orchestration

Customers see a completely different architecture. They visit a product page and expect to see everything they need to make a purchase decision. Product details, current pricing, inventory availability, customer reviews, related products, and applicable promotions. That information spans multiple resource services, but customers see one cohesive experience.

Behind the scenes, an orchestration service gathers data from multiple resources, applies business logic to combine them intelligently, and returns everything the page needs in one optimized response. The customer gets a fast, cohesive experience. The front-end developer makes one clean API call that returns structured data ready for rendering.

Storefront interactions also benefit from orchestration services that understand customer context. The same product might have different prices for different customer segments. Inventory availability might vary by geographic region. Promotions might be targeted to specific customer groups. Orchestration services apply all this contextual logic automatically, returning personalized responses without forcing the front-end to understand complex business rules.

The Utility Layer: Infrastructure That Just Works

Three core utility services handle the foundational concerns that make everything else possible. These services are invisible to end users but critical for the platform's operation.

Authentication and Authorization: Security Done Right

Every service in a microservices architecture needs security, but duplicating authentication and authorization logic across 30+ services would be a maintenance nightmare. Our Auth Service centralizes all authentication and authorization using the industry-standard OAuth 2.0 framework.

Here's how it works in practice. Users log in once through the Auth Service and receive a JWT (JSON Web Token). That token contains cryptographically signed claims about their identity and permissions. Every subsequent API request includes this token in the authorization header.

When resource services receive requests, they validate the JWT token without needing to call back to the Auth Service. The token itself contains all the information needed to make authorization decisions. This distributed security model scales efficiently because services can make authorization decisions locally without a network round-trip.

The Auth Service also handles complex authorization scenarios like role-based access control, resource-level permissions, and temporary access grants. A merchandiser might have permission to edit products in certain categories but not others. A customer service representative might have read-only access to order information but full access to customer profiles. The Auth Service encodes these complex rules into JWT tokens that resource services can interpret and enforce.

API Gateway: One Entry Point to Rule Them All

While you can expose 30+ individual services directly to the public internet, that would require significant security and dev ops overhead.  IP address whitelisting and SSL certificate management become unwieldy. API versioning becomes chaotic.

Our API Gateway, built on Spring Cloud Gateway, solves these problems by acting as the single entry point for all external traffic. Every request flows through the gateway, which then routes to the appropriate internal service.

But the gateway does more than simple routing. It handles cross-cutting concerns like CORS (Cross-Origin Resource Sharing) headers for browser-based applications. It manages API rate limiting to prevent abuse. It handles request and response transformation when you need to maintain backward compatibility with older client applications.

The gateway also enables sophisticated Backend-for-Frontend (BFF) patterns. Instead of exposing generic resource service APIs directly, you can create gateway routes that aggregate and transform responses specifically for your front-end applications. A mobile app might need different data structures than a web application. The gateway can provide both from the same underlying services.

For development teams, the gateway provides a clean abstraction layer. Front-end developers work with a consistent API interface regardless of how many services power it behind the scenes. When you need to refactor service boundaries or split services apart, the gateway can maintain API compatibility while the internal architecture evolves.

Configuration Management: Change Without Chaos

Managing configuration files across dozens of microservices creates serious operational challenges. Every service needs database connection strings, third-party API keys, feature flags, and environment-specific settings. Traditional approaches mean either baking configuration into deployment artifacts or managing dozens of separate config files across your infrastructure.

The Spring Cloud Config Server centralizes all application properties in a single, version-controlled location. When services start up, they pull their configuration from the Config Server. This ensures consistency across environments and simplifies configuration management dramatically.

More importantly, the Config Server enables dynamic configuration updates. Need to enable a feature flag across multiple services? Update the centralized configuration and push the change. Services can pick up new configuration values without restarts, enabling rapid feature rollouts and emergency configuration changes.

The Config Server also supports environment-specific configuration with inheritance and overrides. Your development, staging, and production environments can share a base configuration while overriding specific values as needed. Configuration changes are tracked in version control, giving you full audit trails and the ability to roll back problematic changes.

Why This Architecture Delivers Real Business Value

Broadleaf's four-tier architecture isn't just about technical elegance. It delivers concrete business benefits that matter to commerce companies trying to compete in fast-moving markets.

Each service in the resource tier focuses on doing one thing exceptionally well. The Catalog service doesn't worry about pricing calculations. The Pricing service doesn't handle inventory tracking. This focused responsibility means faster development cycles, easier testing, and more reliable systems. When you need to add new catalog features, you work in one focused codebase without worrying about breaking unrelated functionality.

The orchestration layer provides the flexibility to create exactly the customer experiences you want. Need to build a mobile app with different data requirements than your web application? Create orchestration endpoints tailored to each platform. Want to A/B test different product recommendation algorithms? Implement the variations in orchestration services without touching your core catalog functionality.

For development teams, this architecture enables true parallel development. Your catalog team can work independently from your pricing team. Your front-end developers can build new experiences without waiting for backend changes. Teams can deploy their services independently, reducing coordination overhead and enabling faster release cycles.

The modular approach also reduces technical debt over time. When you need to change how pricing calculations work, you modify the Pricing service. When you need to integrate with a new inventory management system, you update the Inventory service. Changes stay contained within service boundaries, reducing the risk of unexpected side effects.

This flexibility becomes critical as your business grows and evolves. New market requirements don't force you to refactor your entire platform. New integration requirements don't require massive cross-cutting changes. You can adapt individual pieces of your architecture while keeping the rest of your system stable and running.

This flexibility becomes especially important when you're dealing with the realities of modern commerce. Markets shift quickly. Customer expectations evolve constantly. New technologies emerge that could give you competitive advantages, but only if you can integrate them quickly.

Traditional monolithic platforms force you into their way of doing things. Want to use a different recommendation engine? You might need to replace your entire catalog system. Need to integrate with a new payment provider? That could require changes throughout your checkout flow. Want to experiment with different pricing strategies? You're limited by what the monolith supports.

With Broadleaf's composable architecture, you have different options. Need better product recommendations? Swap out or enhance the orchestration service that handles catalog browsing. Want to try a new payment processor? Update the payment service without touching anything else. Ready to implement dynamic pricing? Enhance the Pricing service while everything else keeps running.

The real test of any architecture comes during peak seasons and unexpected traffic spikes. Black Friday doesn't care about your elegant code if your checkout process crashes under load. With microservices, you can scale the bottlenecks independently. Maybe your catalog browsing needs 10x more capacity, but your admin services are fine. Scale what needs scaling, leave the rest alone.

Maintenance and updates become manageable, too. Security patches don't require full system downtime. New features can be developed and deployed independently. Bug fixes are contained to the services that need them. Your development teams can move faster because they're not stepping on each other's code.

Building Commerce That Lasts

The software industry loves to talk about technical architecture, but what really matters is whether your platform can grow with your business. Can it handle the complexity that comes with success? Can it adapt when your market changes? Can your development teams stay productive as your codebase grows?

Broadleaf's four-tier microservices architecture answers "yes" to all of these questions. Resource services provide the solid data foundation your business depends on. Orchestration services create the flexible customer experiences that drive revenue. Admin services give your teams the tools they need to manage complexity. Utility services handle the technical details so everyone else can focus on business logic.

You're not just getting a commerce platform when you choose this architecture. You're getting the flexibility to build exactly what your customers need, the ability to adapt when markets change, and the scalability to handle whatever growth brings your way.

That's what composable commerce really means. Not just technical buzzwords, but real business capability that grows with you.