Architecture patterns

architecture-patterns.md

Topic	N Tier	Web-Queue-Worker	Microservices	Event-driven architecture	Big Data, Big Compute
Definition	N-tier is a traditional architecture for enterprise applications. Dependencies are managed by dividing the application into layers that perform logical functions,	Web-queue-worker is suitable for relatively simple domains with some resource-intensive tasks. Like N-tier, the architecture is easy to understand. The use of managed services simplifies deployment and operations.	f your application has a more complex domain, consider moving to a Microservices architecture. A microservices application is composed of many small, independent services.	Event-Driven Architectures use a publish-subscribe (pub-sub) model, where producers publish events, and consumers subscribe to them. The producers are independent from the consumers, and consumers are independent from each other.	Big Data and Big Compute are specialized architecture styles for workloads that fit certain specific profiles. Big data divides a very large dataset into chunks, performing parallel processing across the entire set, for analysis and reporting.
Architecture	layers are arranged horizontally in presentation, business logic, and data access. A layer can only call into layers that sit below it.	The front end communicates to the worker through an asynchronous message queue.	Each service implements a single business capability. Services are loosely coupled, communicating through API contracts. Each service can be built by a small, focused development team. Individual services can be deployed without a lot of coordination between teams, which encourages frequent updates.	An event-driven architecture for applications that ingests and process a large volume of data with very low latency, such as IoT solutions. The style is also useful when different subsystems must perform different types of processing on the same event data.	Big compute, also called high-performance computing (HPC), makes parallel computations across a large number (thousands) of cores. Domains include simulations, modeling, and 3-D rendering.
Featres & use cases	Horizontal tiers divided by subnet	Front and backend jobs, decoupled by async messaging	Vertically (functionally) decomposed services that call each other through APIs	Producer/consumer. Independent view per sub-system.	Divide a huge dataset into small chunks. Parallel processing on local datasets Data allocation to thousands of cores.
	Traditional business domain. Frequency of updates is low	Relatively simple domain with some resource intensive tasks.	Complicated domain. Frequent updates	IoT and real-time systems	Batch and real-time data analysis. Predictive analysis using ML. Compute intensive domains such as simulation
Scalability	horizontal layering can be a liability. It can be hard to introduce changes in one part of the application without touching the rest of the application. That makes frequent updates a challenge, limiting how quickly new features can be added.	same as N tier	Quite scalabale but comes with extra overhead of complexity and maintenance	Easy to scale but difficult to achieve scalable overheads such as fault tolenrance/maintencne etc.	Difficult to scale and difficilt to manage
Applications	N-tier is a natural fit for migrating existing applications that already use a layered architecture. For that reason, N-tier is most often seen in infrastructure as a service (IaaS) solutions, or application that use a mix of IaaS and managed services.	For a purely PaaS solution, consider a Web-Queue-Worker architecture. In this style, the application has a web front end that handles HTTP requests and a back-end worker that performs CPU-intensive tasks or long-running operations.	E commerce	IoT applications	Machine Leanring & Quantum

testing converter

update using this link - https://tabletomarkdown.com/convert-spreadsheet-to-markdown/

Topic	Complexity	Asynchronous & Consistency	Inter-operability	Manageability	Time & Cost
Consderations	Is the complexity of the architecture justified for your domain? Conversely, is the style too simplistic for your domain? In that case, you risk ending up with a "big ball of mud", because the architecture does not help you to manage dependencies cleanly.	Asynchronous messaging can be used to decouple services, and increase reliability (because messages can be retried) and scalability. However, this also creates challenges in handling eventual consistency, as well as the possibility of duplicate messages.	Inter-service communication. As you decompose an application into separate services, there is a risk that communication between services will cause unacceptable latency or create network congestion (for example, in a microservices architecture).	How hard is it to manage the application, monitor, deploy updates	How much time will it take to develop, the costs associalted with the and the skills of your developers & Devops to build it