Skip to main content
// architecture ecosystem

Typical Software Design Patterns

Architecture is a set of trade-offs, not a trend. This is how we model existing systems, choose a target architecture, and move a platform from one to the other without stopping the business.

// model 01

The legacy monolith

One deployable, one database, and years of accumulated coupling. It still runs the business — which is exactly why it can't be switched off. The constraint is rarely the code; it is that every change touches everything.

MONOLITHIC DEPLOYMENT UNITAuthBillingOrdersReportingAdminBatch JobsShared database
// model 02

API-driven architecture

Capabilities are exposed as versioned contracts behind a gateway. Each service owns its data, deploys on its own cadence, and can be scaled, replaced, or instrumented without a coordinated release.

WebMobilePartner APIAPI GATEWAY · CONTRACTSIdentityown dataPaymentsown dataCatalogown dataNotificationsown dataindependent deploys · versioned contracts · observable boundaries
// modernization in motion

Strangler fig: modernize without a rewrite.

Instead of a multi-year big-bang replacement, we grow the new platform around the old one. Each step is independently valuable and independently reversible.

ClientsROUTINGFAÇADELegacy monolith4 capabilities remainingIdentity serviceOrders serviceBilling serviceReporting service
// strangler fig pattern

01 · Baseline the monolith

All traffic hits the legacy application. We instrument it, map domains, and document the real behavior before touching code.

  • 01 · Baseline the monolith
  • 02 · Insert the façade
  • 03 · Extract the first capability
  • 04 · Migrate domain by domain
  • 05 · Retire the legacy core
// choosing a target

Architecture patterns and their trade-offs.

Modular monolith

Use when
Small teams, one deployable, clear domain boundaries in code.
Trade-off
Fast to build and reason about; scaling and release independence are limited.

API-driven services

Use when
Multiple teams, differing scaling profiles, partner or multi-client access.
Trade-off
Independent deploys and clean contracts; requires real platform discipline.

Event-driven backbone

Use when
High-volume workflows, audit requirements, asynchronous integrations.
Trade-off
Resilient and decoupled; demands schema governance and idempotency.

Composable platform

Use when
Enterprise ecosystems assembling internal and third-party capabilities.
Trade-off
Maximum reuse and optionality; integration and identity design get harder.
// signals

When a platform is ready to evolve.

If several of these are true, the architecture — not the team — is the bottleneck.

  • A single release train blocks every team
  • Database schema changes require cross-department coordination
  • Scaling one feature means scaling the entire application
  • Vendor or framework versions are past end of support
  • No test suite anyone trusts before a production deploy
  • Institutional knowledge lives with two or three people
// let's build

We build Exceptional.

Whether it is an MVP for a new product you're trying to bring into the world, or an enterprise system that needs creating or maintaining, we can help. Professionally engineered, documented, and maintained.