Event Driven Architecture

Lydtech

Benefiting from the advantages of event driven architectures doesn’t have to mean a wholesale shift in your approach to interprocess communications. We help take the implementations you already have and assist you in your migration to a scalable alternative

Many organisations find the number of options available in this area overwhelming, and are unaware of the implications when making choices on system behaviour early on. We have successfully designed and built many event driven architectures, and we can help you identify the correct technologies and strategies to make this adoption a positive and efficient experience.

Event Driven Architecture with Lydtech

     Loosely Coupled

     Asynchronous Communication

     Separation of Responsibilities

     Streaming

     Idempotency

     Temporal Unavailability Protection

     Transactionality

     Resilience

     Eventual Consistency

     At least once delivery

     Deduplication


Expertise in Event Driven Architecture Delivery

Safety in Separation

The loose coupling of an event architecture boosts the resiliency of your system. Your service is decoupled from the failures in other services. Additionally your surface is also protected from a flood of events due to the buffering provided by the middleware.

At Lydtech we understand that ensuring a clean handoff between services helps ensure the predictability of your system. Whether you are using techniques such as Change Data Capture (CDC), or direct engagement with the message broker APIs. Having a validated understanding of the transactional behaviour during a handoff is essential to establishing a high level of confidence when operations do not follow the happy path.

Separation of Responsibilities

Decoupling between services allows each service to perform its own tasks independently, and protects that service from problems in other services. Producers do not need to be aware of consumers, consumers are only concerned about the events they receive.

Services should remain completely autonomous, a change in one service should not require a change in another service.

Separation of responsibilities is something that needs to be determined before you reach implementation. Domain Driven Design is an approach we use to organise the often spaghetti like logic of complex systems.

Expertise in Event Driven Architecture Delivery

Asynchronous Communication

The push based nature of event driven communication removes the need for real-time request-response interactions, meaning the reply does not have to happen immediately for normal operation of the system. Eliminating the dependencies on responses eliminates blocking operations encountered with synchronous communications.

Complexity often arises from seemingly innocuous workflows when you explore the failure options. Asynchronous communication will provide you with a more robust system, but only if you take into consideration the failure points and design in the failure handling requirements.

The Outcomes

Scalability

Breaking the direct link between services enables many workers to pick up the tasks, well beyond the scale a request/response architected solution could ever achieve

Eventual Consistency

Decoupled and decentralized systems offer a more natural approach to service provision, but encounter challenges from networks that are less prevalent in monolithic systems

Extensibility

Without the tight coupling between services, extension and integration becomes a simpler task