Style versus Pattern
The distinction between a system-wide organising structure and a reusable solution to a recurring problem within it.
A style is a global structural choice: layered, microservices, event-driven, pipe-and-filter, service-based, space-based. It determines how the system is decomposed and how the parts communicate, and changing it is a rewrite.
A pattern solves a recurring problem inside whatever style is chosen: circuit breaker, saga, CQRS, strangler fig, sidecar. Patterns are composable and can be adopted incrementally.
Why the distinction is worth holding: style is a small number of very expensive decisions; patterns are many cheap ones. Teams frequently debate patterns at length while the style was chosen by default — usually by whatever the first service looked like.
A system normally has one dominant style with local variation: an event-driven core with a layered service inside each component, or a modular monolith with a few extracted services. Purity is not a goal, and the styles are not mutually exclusive at every level.
The choice follows the driving quality attributes rather than fashion. Layered suits simple deployment and a small team; event-driven suits decoupling and variable load at the cost of debuggability; microservices suit independent deployment by many teams and impose distributed-systems complexity on everything.