Common Software Architecture Patterns and Their Considerations

Developers often start coding without a formal architecture, leading to tightly‑coupled, hard‑to‑maintain systems; a clear architectural pattern helps define system characteristics such as scalability, agility, and modularity.

Layered Architecture

Also known as n‑tier architecture, it divides an application into layers (presentation, business, persistence, database). Each layer has distinct responsibilities, promoting separation of concerns and easier testing, but can become a "architecture sinkhole" if layers contain little logic.

Key concepts include strict layer isolation—requests must pass through each layer—and the ability to add new layers (e.g., a service layer) without affecting others. However, overly strict isolation may lead to "open layers" that bypass intermediate layers.

Event‑Driven Architecture

This distributed asynchronous pattern consists of event queues, a mediator or broker, event channels, and processors. Two topologies exist:

Mediator : coordinates multi‑step events, arranging processing order and parallelism.

Broker : a lightweight message broker (e.g., RabbitMQ, ActiveMQ) directly connects events without a central coordinator.

Examples include Sina Weibo’s shift from synchronous push to asynchronous push‑pull using a message queue, improving response time and scalability.

Considerations: added complexity, distributed reliability issues, lack of atomic transactions across processors, and the need to manage many event types.

Microkernel Architecture

Also called plugin architecture; core system plus plug‑in modules allow extensibility (e.g., Eclipse IDE). It enables incremental feature addition and can be embedded within other architectures.

Pros: high flexibility, good testability, high performance; cons: lower scalability and higher development effort.

Microservices Architecture

Decomposes applications into independently deployable service components, often communicating via REST, messaging, or RPC. It evolves from monolithic or SOA approaches and solves many problems of large‑scale systems, though it inherits distributed system challenges.

Typical topologies include API‑REST, application‑REST, and centralized messaging. Each service can be scaled independently, but design of service granularity is critical.

Space‑Based Architecture

Also known as cloud‑based architecture, it eliminates a central database bottleneck by using a replicated in‑memory data grid across processing units, managed by virtualized middleware. Suitable for variable‑load web applications but costly for large relational workloads.

Considerations: high complexity and expense; good for scaling out but not ideal for traditional RDBMS‑heavy systems.

Overall, selecting an architecture requires weighing flexibility, deployment ease, testability, performance, scalability, and development effort against the specific business needs and constraints of the project.