According to Wikipedia, “An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context. Architectural patterns are similar to software design patterns but have a broader scope.” Let’s look at a few common architectural patterns, Monolithic Architecture In monolithic architecture, the . Sometimes specified with hundreds of thousands of lines of source code. A well-structured monolith can give you needed efficiency at the cost of very slow and painful deployment. entire program is one large executable unit But there is a drawback with a monolith, which is that everybody’s afraid to touch it, even a in unexpected places. Work that should take a few hours can take weeks. small change can cause problems Microkernel (plugin) Architecture The main idea behind the Microkernel (plugin) architecture . for example, In an operating system, the kernel handles virtual memory and the file system. Other capabilities are implemented as stand-alone execution units that effectively plug into the kernel to do their work. is to put the essential capabilities of your system into a single stand-alone executable Microkernel architectures are a step up from monoliths in several ways. The main one is that t . Typically, the plugins don’t know how other plugins work or if the other plugins even exist for that matter. he plugins are largely independent of one another The plugins are also relatively small and easy to write, debug, and maintain, so you don’t have the problems associated with not being able to find things, or of the system being so complex that you can’t possibly understand it. On the , the kernel itself, or more correctly the APIs to the kernel, are very delicate. . downside If you need to make a necessary change to those APIs, all of the plugins might need to be rewritten to use the new APIs Message-based Architectures This architecture takes the notion of a microkernel a step further by even further. formalizing the communication paths between elements and isolating them In message-based architecture, A common message bus controlled the flow of communication. Each application was fitted with a so-called adapter that talked to the message bus on one side and talked to the application on the other. In another model of message-based architecture which is called pub/sub model, associated with a specific topic. on that topic. Publishers publish messages Subscribers can subscribe to a topic and receive messages from any publisher Message-based architectures allow the components of the system to be . Each component is effectively a small, standalone program that can be maintained independently of other programs. That , and it solves the dependency problems of a microkernel system. isolated in extreme ways decoupling makes your system vastly more maintainable than a monolith On the downside, messaging systems quickly become highly complex, and managing that complexity is difficult. Microservices and Miniservices In a microservice architecture, the . larger system is made up of a cloud of very small independent services that cooperate as peers to get the larger work done In the earlier chapter that discussed defense storming, you’d implement the agents or entities that emerged from that exercise as individual microservices. Those services can be spread across a network, even across the whole internet, and redundancy is built-in. Many instances of the same service, for example, could run in parallel. Put those things together and you get a . Microservices are not just tiny monoliths. They have to be designed in a way that very resilient system that can easily handle whatever stress you throw at it supports distributed deployment and complex real-time interactions. microservices should be be independently deployable translates into a few hundred lines of source code written in a way that hides all the implementation details designed to work in an unreliable network environment highly observable, They log everything they do. You can monitor how well they’re running in real-time. So if services fail, you know why they failed. When you implement microservices the main problems usually have to do with how the services communicate with each other. People take two main approaches. The first is to make each service a small HTTP-based web service that you talk to using a REST-like protocol. The main downside of a post-based API is that it’s inherently synchronous, rather heavyweight, and has several error modes that are difficult to solve. The second approach is messaging instead of HTTP. There are many advantages to microservices, particularly in an agile environment where you constantly need to make small changes to a handful of services and deploy them very quickly. The main . Getting multi-step operations to work reliably across a network is just plain hard work. . Networks are just slow when compared to other alternatives. downside of microservices is they come with a lot of both design and runtime complexity Microservices also come with a speed hit Reactive and Choreographed Systems In a Reactive and choreographed system, the system is issuing events instead of making requests. It broadcasts the event to the world, and any downstream services that are interested in that fact can do whatever they need to do in order to handle the event. Reactive and choreographed system is faster than microservice architecture. All of the downstream processing is easily done in parallel, so the worst-case latency is typically the processing time of the slowest downstream process. I hope this article helped you to learn about a few architectural patterns and their benefits and drawbacks., If you want to learn more you can follow the work of Grady Booch, Mark Richards, Simon Brown, and Neal Ford. Do comment and share and let me know if you like it, your small effort encourages me to write more. Also Published here

Flow

2022 - HackerNoon Contributor of the Year - Best Practices

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Frontend

2022 - HackerNoon Contributor of the Year - Microservices

2022 - HackerNoon Contributor of the Year - Product Development

2022 - HackerNoon Contributor of the Year - React

2022 - HackerNoon Contributor of the Year - Software Architecture

Nominated for 2022 - HackerNoon Contributor of the Year - Product Development

Nominated for 2022 - HackerNoon Contributor of the Year - Microservices

Nominated for 2022 - HackerNoon Contributor of the Year - React

Nominated for 2022 - HackerNoon Contributor of the Year - Frontend

Nominated for 2022 - HackerNoon Contributor of the Year - Best Practices

Nominated for 2022 - HackerNoon Contributor of the Year - Software Architecture

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Senior Software Engineer

Too Long; Didn't Read

Get free API security automated scan in minutes

3 Architectural Design Patterns for Software Development

3 Architectural Design Patterns for Software Development

Too Long; Didn't Read

People Mentioned

Coin Mentioned

@ruchikamourya

RELATED STORIES