Architectures

MACH Architecture

In the fast-paced digital world, traditional enterprise software is becoming outdated. MACH architecture offers a modern alternative, enabling businesses to stay agile and customer-centric.

What is MACH Architecture?

MACH stands for Microservices-based, API-first, Cloud-native, and Headless. This architecture provides a flexible and scalable foundation for digital transformation.

Components of MACH Architecture:

• Microservices: Independent units of business functionality.
  • Characteristics: Allows for separate development and deployment, enhancing agility.
• API-first: All functionalities are accessible via APIs rather than being an afterthought or add-on to existing features.
  • Characteristics: Facilitates easy integration and modularity.
• Cloud-native: Software fully utilizes cloud capabilities.
  • Characteristics: Supports elastic scaling and automatic updates.
• Headless: Front-end is decoupled from back-end logic.
  • Characteristics: Enables flexible UI design across various platforms.

Benefits of MACH Architecture

1. Improved Speed and Lower Risk: By enabling the independent development and deployment of microservices, MACH architecture accelerates the creation of MVPs (Minimum Viable Products), allowing faster launches and iterations. This independence limits the risk of system-wide failures, facilitating smoother rollouts and easier issue resolution.
2. Best-of-Breed Strategy: MACH supports integrating the best tools for specific functions, avoiding the constraints of monolithic suites. Businesses can select and integrate optimal technologies for each component, preserving existing investments and enabling easy upgrades as new, superior tools emerge.
3. No Disruptive Upgrades: Continuous delivery ensures automatic and seamless updates, eliminating the need for manual upgrades and reducing downtime. This approach provides non-breaking changes, allowing businesses to stay current without disrupting operations.
4. Seamless Customizations: MACH’s decoupled structure allows rapid adaptation to evolving customer needs. Businesses can quickly implement new features or improvements, fostering continuous innovation and enhancing the customer experience without overhauling the entire system.

Evaluating MACH Architecture

• Microservices
  • True Microservices: Independent scaling and updates.
  • Phased Roll-outs: Incremental implementation of services.
  • Best-of-Breed: Integrate or replace systems independently.
• API-First
  • Built with APIs: APIs integral to system design.
  • Quality Documentation: Comprehensive and accessible.
  • Integration: APIs, webhooks, and connectors for easy interaction.
• Cloud-Native
  • Scalability: Advanced scaling for growing demand.
  • SaaS Delivery: Entirely cloud-based with SLAs.
  • Continuous Delivery: Automatic updates without disruption.
• Headless
  • No Built-In UI: Freedom in UI development.
  • Flexible UI Development: Use any tech stack for user interface design.

Event-Driven Architecture

Source: AWS - What is an Event-Driven Architecture?

An event-driven architecture uses events to trigger and communicate between decoupled services and is common in modern applications built with microservices. An event is a change in state, or an update, like an item being placed in a shopping cart on an e-commerce website. Events can either carry the state (the item purchased, its price, and a delivery address) or events can be identifiers (a notification that an order was shipped).

Event-driven architectures have three key components: event producers, event routers, and event consumers. A producer publishes an event to the router, which filters and pushes the events to consumers. Producer services and consumer services are decoupled, which allows them to be scaled, updated, and deployed independently.

There are two main types of routers used in event-driven architectures: event buses and event topics. At AWS, we offer Amazon EventBridge to build event buses and Amazon Simple Notification Service (SNS) to build event topics.

What Does Decoupled Mean?

Decoupled, or decoupling, is a state of an IT environment in which two or more systems somehow work or are connected without being directly connected.

In a decoupled microservices architecture, for example, software services have none or very little knowledge about the other services. In theory, this means that a change can be made to one service without the developer having to worry about how the change will impact other services -- as long as the service's application programming interface (API) remains the same.

A decoupled architecture allows software development teams to build, execute, test and debug application modules independently. This approach also allows each module to be developed and maintained by a different team of software developers.

Event-Driven Systems vs Request-Response Systems

Event-based systems differ markedly from request-based systems. Event-based and request-based systems are duals of each other. Whereas the receipt of a request triggers the action of a request-response system, the receipt of an event triggers event-driven systems.

The nature of an event is different from that of a request.

• A request says, "Do this for me." In contrast, an event says, "This happened."
• In a request-driven system, the sender chooses what action to take. In an event-driven system, the sender merely says that something happened.
• Event processors have no obligation to the event generator. Event generators are obligated to report events and respond to directives. Conversely, a client in a request-driven system has no obligation to the server. A client can make a request or not. Servers are expected to fulfill requests.
• Event processors interpret what an event means. A request, on the other hand, implies that the interpretation of what should happen has already occurred. You can think of this as receiver, instead of sender, determinism.

	Request-Based	Event-Based
Signal	Request receipt	Event receipt
Nature	"Do this"	"Something happened"
Obligation	At server	At event generator (client)
Interpretation	On client	On server

Benfits of Event-Driven Architecture

• Scale and fail independently
  • With microservices focused on doing one thing well and no tight coupling to other services, you can individually scale the services that have the largest workload in order to ensure that each microservice is up to date with its work log.
  • if one service has a failure, the rest will keep running. The event router acts as an elastic buffer that will accommodate surges in workloads.
• Develop with agility
  • You no longer need to write custom code to poll, filter, and route events; the event router will automatically filter and push events to consumers.
  • The router also removes the need for heavy coordination between producer and consumer services, speeding up your development process.
• Audit with ease
  • An event router acts as a centralized location to audit your application and define policies. These policies can restrict who can publish and subscribe to a router and control which users and resources have permission to access your data.
  • You can also encrypt your events both in transit and at rest.
• Cut costs
  • Event-driven architectures are push-based, so everything happens on-demand as the event presents itself in the router.
  • This way, you’re not paying for continuous polling to check for an event. This means less network bandwidth consumption, less CPU utilization, less idle fleet capacity, and less SSL/TLS handshakes.

Drawbacks of Event-Driven Architecture

• Over-engineering of processes — Sometimes a simple call from one service to another is enough. If a process uses event driven architecture, it usually requires much more infrastructure to support it, which will add costs (as it will need a queueing system)
• Inconsistencies — Because processes now rely on eventual consistency, it is not typical to support ACID (atomicity, consistency, isolation, durability) transactions, so handling of duplications, or out of sequence events can make service code more complicated, and harder to test and debug all situations.
• Rollbacks are complex — Managing distributed transaction could be complex. There are multiple services that consume an event, as a result, if an exception occurred in one of the services, what should happen to the entire flow or implementing a rollback process is challenging.

A few points to consider when applying event-driven architecture

• The durability of your event source. Your event source should be reliable and guarantee delivery if you need to process every single event.
• Your performance control requirements. Your application should be able to handle the asynchronous nature of event routers.
• Your event flow tracking. The indirection introduced by an event-driven architecture allows for dynamic tracking via monitoring services, but not static tracking via code analysis.
• The data in your event source. If you need to rebuild state, your event source should be deduplicated and ordered.