| Architecture | Description | When to Use | Pros | Cons | Frameworks (Node.js / Python) | Use Cases |
|---|---|---|---|---|---|---|
| Monolith | Single deployable app | MVPs, small apps | Simple to build & deploy | Hard to scale or isolate modules | Express, Flask, FastAPI, Django | Dashboards, admin panels |
| Modular Monolith | Organized monolith with domains/modules | Growing apps | Scalable within single codebase | Shared runtime, still coupled | NestJS, Django-Ninja, FastAPI (modular) | Internal tools, feature-rich SaaS |
| Microservices | Independently deployed services | Enterprise apps | Independently scalable, team autonomy | Complex infra, inter-service comms | Express, Fastify / FastAPI, Flask, Django REST | E-commerce, marketplaces |
| Serverless | Functions triggered by events (Lambda, etc.) | Low-latency, event-based needs | Pay-per-use, scales automatically | Cold starts, limited execution time | Node.js (AWS Lambda, Vercel) / Python (Zappa, Chalice) | Auth APIs, webhooks |
| Event-Driven | Services interact via pub/sub messaging | Real-time and async processing | Loose coupling, scalable | Debugging and state tracking is harder | Node.js + NATS/RabbitMQ / Python + Celery/Kafka | Notifications, analytics |
| CQRS + Event Sourcing | Split read/write + event stream persistence | Audit logs, financial systems | Query/read optimization, replayable state | High complexity, requires infra setup | NestJS (CQRS) / FastAPI + Kafka, EventStore | Ledgers, bookings |
| Backend For Frontend | One backend per frontend (web/mobile) | Apps with tailored UI needs | Custom responses, less over-fetching | Code duplication between backends | Express, Fastify / FastAPI, Flask | Separate web & mobile apps |
| GraphQL-Centric | Unified GraphQL layer exposing services | Dashboard, complex UIs | Flexible client queries | Schema design, query complexity | Apollo Server, Mercurius / Strawberry, Ariadne | Multi-client APIs |
| JAMstack Backend | Static frontend + backend APIs | Lightweight marketing sites | Fast, scalable hosting | All logic must go through APIs | Next.js + API routes / Flask + Netlify Functions | Landing pages, calculators |
| Headless CMS-Based | CMS with extendable logic via custom APIs | Content-heavy platforms | Easy content management | Flexibility limited by CMS | Strapi (Node), Keystone / Wagtail, Netlify CMS | Blogs, eCommerce |
| Architecture | Description | When to Use | Pros | Cons | Node.js / Python Compatibility | Used In |
|---|---|---|---|---|---|---|
| MVC | Model, View, Controller layers | Small to mid apps | Easy to grasp | Not great at scale | Express, Sails / Flask, Django | Monoliths, CRUD apps |
| Layered | Separate controller, service, repo layers | General-purpose apps | Logical separation | Layers may become shallow | Express, NestJS / FastAPI, Django | API backends |
| Clean Architecture | Entities → UseCases → Interfaces → Framework | Testable, scalable apps | Highly decoupled | Verbose, complex setup | NestJS / FastAPI (manual), CleanPy | Large SaaS, microservices |
| Hexagonal Architecture | Core logic via ports/adapters | Integration-heavy apps | Pluggable, isolated logic | Setup complexity | Express / Python Hexagonal Boilerplates | Plugin systems, external API integrations |
| Onion Architecture | Centered on domain, outer layers add infra | Domain-centric logic | Controlled dependencies | Verbose for small projects | NestJS / FastAPI, Django (manual) | Enterprise apps |
| CQRS | Separate command and query logic | Write-heavy, real-time flows | Efficient and scalable | Needs coordination logic | NestJS CQRS / Python (custom FastAPI + command bus) | Financial or booking systems |
| DDD (Domain Driven) | Structure based on domain logic | Complex business logic | Matches business language | Needs domain expertise | NestJS / Python (Dependency Injector, DDD libs) | Multi-entity SaaS |
| Event Sourcing | Store state as events | Audit + history-focused apps | Full traceability | Harder consistency management | Kafka/EventStore with Node or Python | CRMs, financial systems |
| Plugin-Based | Core + dynamic plugins for features | Dev tools, extensible backends | Easy to add features | Plugin lifecycle mgmt needed | Strapi / Django CMS, Flask plugins | CMS, IDEs |
| Functional Core / Imperative Shell | Logic in pure functions, I/O handled separately | Test-driven, FP-influenced apps | High testability | Harder for imperative logic |
/app
├── controllers/
│ └── user_controller.*
├── models/
│ └── user_model.*
├── views/
│ └── user_view.* # (HTML, templates, etc.)
├── routes/
│ └── user_routes.*
└── app.*
/app
├── controllers/
│ └── user_controller.*
├── services/
│ └── user_service.*
├── repositories/
│ └── user_repository.*
├── models/
│ └── user_model.*
└── main.*
/app
├── domain/
│ ├── entities/
│ └── value_objects/
├── use_cases/
│ └── create_user.*
├── interfaces/
│ ├── controllers/
│ └── routes/
├── infrastructure/
│ ├── database/
│ └── external_services/
└── main.*
/app
├── core/
│ └── domain_logic.*
├── ports/
│ ├── user_repository_port.*
├── adapters/
│ ├── database/
│ └── external_api/
├── interfaces/
│ └── http/
└── main.*
/app
├── domain/
│ └── entities/
├── application/
│ └── use_cases/
├── infrastructure/
│ ├── database/
│ └── messaging/
├── interfaces/
│ └── controllers/
└── main.*
/app
├── commands/
│ └── handlers/
├── queries/
│ └── handlers/
├── events/
│ ├── emitters/
│ └── listeners/
├── projections/
├── infrastructure/
│ └── event_store/
└── main.*
/app
├── users/
│ ├── domain/
│ ├── application/
│ ├── infrastructure/
│ └── interfaces/
├── auth/
│ ├── domain/
│ ├── application/
│ └── interfaces/
└── main.*
/app
├── core/
│ └── engine.*
├── plugins/
│ ├── analytics/
│ ├── auth/
│ └── payments/
├── interfaces/
│ └── api/
└── main.*
/app
├── core/
│ └── pure_logic/
├── shell/
│ └── http_handlers/
└── main.*