Oops! Something went wrong while submitting the form
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.
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.
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.
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.
