An In-Depth Guide to Event-Driven Architecture: What It Is, How It Works, and Why You Need It.

An In-Depth Guide to Event-Driven Architecture: What It Is, How It Works, and Why You Need It.

Wojciech Gębiś - September 15, 2022

As software becomes more data-intensive, developers are increasingly looking to event-driven architecture as a way to handle the load. Event-driven architecture (EDA) is a software design pattern that encourages the development of systems as a series of loosely coupled events. This type of architecture has gained in popularity in recent years, as developers have come to realize the benefits it offers, especially when it comes to scalability and flexibility.

In this article, we will explore what event-driven architecture is, how it works, and when to apply it. We will also discuss some common challenges associated with using EDA and offer some tips for overcoming them.

Why do Businesses Need to Be Ready to Approach Event-Driven Architecture Now?

Before we jump into the technicalities of this software pattern, let’s briefly discuss the needs of businesses when it comes to modern IT infrastructure. The pace of change impacts all businesses, whether they realize it or not. Organizations are building multiple applications and internal software solutions, using plenty of SaaS platforms, and consuming additional data from external services daily. They are also leaning towards different, new feeds that provide information like IoT and edge devices or 5G. End users expect ultralow response times as they are used to real-time solutions, and they need to be available with 100% uptime. These are all needs that businesses have to be prepared for.

As a result, the systems they use need to handle this increased load and data volume efficiently. They also need to process this data quickly and make decisions accordingly. Organizations need to become agile and prepared for their next steps and be proactive about it. They need to be ready to scale their solutions flexibly with yet another application, real-time analytics, or a custom machine learning model.

Traditional rule-based and workflow-based architecture simply does not support this kind of elasticity and agility, especially regarding hybrid or cloud environments and solutions at scale. This is where event-driven architecture comes into play.

Designing Event-Driven Systems

Event-driven architecture is a software architecture based on events’ production, detection, and consumption.

In an event-driven system, events are generated by one or more producers. These events are then received by one or more consumers, who take some action in response to the event. For example, a consumer might save the event to a database or trigger another process in response to the event.

Reactive Manifesto

When we talk about event-driven applications, we cannot forget about the design pattern of reactive systems and the Reactive Manifesto.

The Reactive Manifesto is a set of principles and guidelines for building responsive, resilient, and elastic systems. The manifesto was created in response to the growing need for systems that can handle modern applications’ increased load and data volume. They are designed to work well in distributed environments where throughput is high, latency is low, and the variety of data is significant. The principles are based on four key characteristics:

  • Responsive: The system should respond promptly to user requests.
  • Resilient: The system should be able to recover from failures gracefully.
  • Scalable: The system should be able to scale up or down as needed.
  • Message Driven: The system should use asynchronous message passing to communicate between components.

Reactive system as in reactive manifesto

If you want to dig deeper into various features of designing data-intensive applications, head over to our recent article: Future According to Designing Data-Intensive Applications.

What Are Events?

In an event-driven architecture, events are the driving force behind the entire system. They are generated by producers and consumed by consumers. Each one can be defined as a significant change in state. Events can be anything from a user clicking a button on a website or a warehouse inventory update to a sensor detecting a temperature change.

Events can be generated by just about anything inside or outside the organization. They can be generated by humans, devices, sensors, or any other type of software system. Some of those can be analyzed in batches, while others need to be processed instantly as the events occur. EDA enables near-real-time processing of events as they happen. Events are immutable (they cannot be changed or deleted) and are published in the order that they were created.

Event-Driven Architecture

As mentioned earlier, an EDA consists of event producers that produce a stream of events and event consumers that listen to the events.

Diagram of an event-driven architecture style

Diagram of an event-driven architecture style

With events being processed in near real-time, consumers can respond as they occur. Producers do not have an insight into which consumers are listening as they are decoupled from them. Consumers are also decoupled from each other but still have access to all events and can subscribe to selected ones. Consumer services receive events without needing to request them and can process them asynchronously.

Event-driven architectures can be modeled in two ways:

Publish-Subscribe Model (Pub/Sub Architecture)

The first is the publish-subscribe model, also known as pub/sub architecture. The messaging infrastructure keeps track of subscriptions through an event router. In this type of architecture, events are published to an event bus, which acts as a message broker between producers and consumers. The event bus forwards events to all subscribed consumers. Once they are forwarded, they cannot be consumed again or by new consumers.

Event driven architecture pattern: event channel based on publisher-subscriber model (pub/sub model)

Event Streaming Architecture

The next model, event streaming architecture, is a little bit more complex yet even more flexible. In this type of architecture, events are stored in an ordered manner within a log, which acts as a broker between event producers and consumers. The log keeps track of all events that have been produced, and they can be stored there even indefinitely. When a new consumer subscribes, it can choose to subscribe to events and read the log from the beginning if needed. Offset allows old consumers to keep track of their position in the stream. This type of architecture is often applied with technologies like Apache Kafka.

Event Streaming Architecture

While taking advantage of the log structure and the broker holding all event data, Kafka and the event stream model are well suited to act as an event store for those who wish to apply event sourcing in their architecture.

If you need a step-by-step guide on the real-life application of Kafka, head over to our blog posts, where we documented the process of building a fast, reliable, and fraud-safe game based on Kafka architecture: Part 1 and Part 2.

Event Processing Patterns

There are three common patterns for processing logic on the consumer side. We can define simple event processing, complex event processing, and event streams.

Simple Event Processing

In this pattern, consumers receive events and process them one at a time. A generated event immediately triggers an action precisely as the event occurs. This is the simplest form of event processing, but it can only be used when the event processing time is short compared to the event generation rate.

Complex Event Processing

In this pattern, consumers process a series of events and look for patterns that span multiple events. This approach can be used to detect anomalies or identify trends. It requires more resources than the other two patterns, but it can provide valuable insights into the data. Apache Storm is an excellent example of a tool that can be used for complex event processing in downstream activity.

Event Stream Processing

In this design, we use a data streaming platform like Apache Kafka as a pipeline to ingest events and send them to stream processors. The stream processors are designed to process or transform the stream. There may be numerous stream processors for different applications’ components. Event stream processing can detect patterns in event streams or aggregate events over time windows.

Event-Driven Architecture - Real World Example

Now that we know the basics of event-driven architecture let’s see how it can be applied in the real world. A good example is a logistics system that needs to process orders and payments, plan transportation, track shipments, and trigger analytics.

In this system, there are six types of events:

  • Quote request
  • Order placed
  • Question about shipment
  • Filed complaint
  • Truck position update
  • Loading/Unloading event

There are three types of event producers:

  • Orders application for shippers
  • Tracking application for shippers and retailers
  • GPS tracking system for trucks and drivers

We can also identify five types of event consumers:

  • Transportation management system (TMS)
  • Pricing engine
  • Track & trace system
  • Finance system
  • Analytics systems

Example of an event-driven architecture for a logistics company

Example of an event-driven architecture for a logistics company

So, let’s see how events flow through this kind of system. First, a shipper can request a pricing proposal from the system by submitting a quote request event. The pricing engine will process this event and generate a quote that is then sent back to the shipper. If the shipper agrees with the price, they will place an order by submitting an order placed event.

This event is processed by the TMS, which plans transportation and assigns it to a truck. The pricing engine consumes order events to adjust the current demand for a particular lane. The truck’s GPS tracking system will start sending truck position update events that are processed by the track & trace system. When the shipment arrives at its destination, the driver sends a loading/unloading event that is received by both retailers and shippers so they can track their shipments. Additionally, the finance module can track order events and payments and process them accordingly. In case of a complaint, the tracking application will generate a filed complaint event.

All important events are also processed further by BI and AI analytics systems.

This system could be further improved by adding more events, such as:

  • An order cancellation event or order update event,
  • A truck maintenance event generated by the truck’s sensors,
  • A customer satisfaction survey event is sent after the complaint is resolved.

And more event consumers, such as:

  • Customer service
  • Technical support

Some consumers can also act as producers and generate their own events as needed. As you can see, event-driven architecture can be used to build complex systems that need to process a high volume of data in real time.

When to Apply Event-Driven Architectures?

Microservices or Decoupled Components

These architectures are well suited for situations where the loose coupling is essential, such as when integrating different independent systems or microservices architecture. When applications are decoupled, teams can work more independently from each other, which makes them faster and more agile.

Integrating Multiple Systems

EDA can also be used to integrate multiple heterogeneous systems that have different tech stacks, and you want to keep them loosely coupled. For example, you may have a legacy system written in one language and a new system written in another. Instead of building point-to-point integrations, you can use an event-driven architecture to integrate them by having one system publish events that the other system subscribes to.

Spreading Same Event to Multiple Event Consumers

When the same event needs to be consumed or processed by multiple applications or services, event-driven architectures can be used to spread the event to all interested consumers (decoupled systems). This approach enables parallel processing, meaning that a single consumer can process the data separately and apply their individual business logic.

Data-Intensive Applications

Event-driven architectures are also well suited for data-intensive applications where large amounts of data need to be processed in real-time. EDA can also handle unpredictable traffic spikes effectively.

Applications Requiring High Availability

Event-driven architectures can improve the availability of an application by decoupling components and making them independent from each other. For example, if one component goes down, the different parts can still continue to work, eliminating the problem of a single point of failure. With the event stream processing approach, you can recover from failure gracefully; once the consumer is up and running, it can retrieve the lost data.

Data Warehouse

EDA can also be used as a data warehouse for reporting and analytics. Data can be collected from multiple data sources and stored in a central location in a unified format. When new data is available, event-driven architecture can be used to trigger an ETL process to load the data into the warehouse. Data analytics or BI systems can request only the required data for their processing needs, like long-running analysis queries. This kind of central data warehouse provides a central view across the organization and enables better decision-making.

Common Use Cases for EDA

Event-driven architectures are well suited for applications that need to process a large number of events in real-time. They are also a good choice for applications that need to be decoupled, scalable, and responsive. Everyday use cases for event-driven architectures include:

  • Messaging technologies,
  • Social networks,
  • Trading systems,
  • Fraud detection systems,
  • Internet of Things (IoT) applications,
  • Core business systems that rely on multiple data sources and more minor services.

Benefits of an Event-Driven Architecture

There are many benefits of using an event-driven architecture, such as:

Decoupling Systems

This architecture is naturally loosely coupled because applications communicate with each other via events that flow through a dedicated pipeline. That makes it easier to develop, test, and deploy applications independently from each other.

Asynchronous Communication

In an EDA, applications don’t have to wait for each other. They can communicate asynchronously, which makes the overall system more responsive and resilient.

Scalability and Ease of Adding New Consumers

EDA makes it easy to deploy and integrate new applications or services without affecting the existing ones. You just need to write a new event consumer subscribes to the events published by the current system. You can also move consumers as you wish without a need to inform other downstream services.

High Throughput and Low Latency

An event-driven architecture can handle a large number of events with low latency. That’s because the overall system is designed to process events independently from each other by separate event channels.

Enabling Push-Based Communication

In this architecture, applications can communicate with each other via push-based communication. That means the event producer doesn’t have to wait for the consumer to request new data. The producer can just push a new event notification as it is generated.

Real-Time Event Streams for Data Science and Analytics

An event-driven architecture can provide a real-time event stream that can be used for data science and analytics. That event stream can be used to build dashboards, run machine learning algorithms, or do any other type of data analysis.

Solid Pipeline for Machine Learning Models Deployment

Deploying machine learning models into production is a difficult task, but EDA can make it much easier. Models that consume events are trained on stream data and can be tested there, and can be deployed in an event-driven production architecture with relative ease (check Rendezvous architecture).

Event-driven rendezvous architecture for machine learning models deployment

Event-driven rendezvous architecture for machine learning models deployment

Business Resilience

All of the above benefits can be summarized as agility and business resilience. Thanks to decoupling, asynchronous communication, and other properties of these architectures, businesses can move faster and adapt to change and growth more efficiently. When appropriately applied, it is the architecture pattern choice for modern organizations that want to have a competitive edge.

Common Challenges When Applying Event-Driven Architecture

Like any other software design pattern, some challenges are associated with event-driven architectures. These challenges include:

Complexity

An event-driven architecture can be complex because it involves many small components that must be integrated and appropriately monitored. Although decoupling is beneficial for multiple reasons, with this pattern, you need to monitor the status of events across various event channels between multiple services versus monitoring point-to-point integrations where the connections are relatively straightforward. The frameworks and the whole architecture are much more abstract and require more understanding to be used properly.

Testing and Debugging

It can also be challenging to test event-driven applications because of that same complexity. It can be hard to mock all the different components and events that need to be processed. Debugging an event-driven system can be challenging because of the asynchronous nature of the processing.

Operational Overhead

An EDA can also have a higher operational overhead than a traditional monolithic architecture or REST integrations. You need to set up advanced monitoring solutions and have a team that can understand this architecture to operate it properly.

Despite those challenges, EDAs offer many benefits that make them well suited for modern software applications that rely on multiple data sources and consist of many app components. They can result in more responsive, scalable, and resilient systems when used correctly.

Building Event-Driven Architectures in Cloud

If you want to build an EDA, many cloud services can help you.

AWS

Amazon AWS provides multiple services that enable EDA implementation. Starting from Amazon EventBridge, which is a serverless event bus that makes it easy to connect applications together using data from your own apps, SaaS apps, and AWS services. Amazon Simple Notification Service (Amazon SNS) is a flexible, fully managed pub/sub messaging and mobile notifications service for coordinating the delivery of messages to subscribing endpoints and clients. Then there is AWS Lambda - a serverless compute service that runs your code in response to events and automatically manages the underlying compute resources for you. You can also take advantage of the fully managed Apache Kafka service - Amazon MSK.

Microsoft Azure

Microsoft Azure provides Azure Event Grid, a fully managed event broker service that allows for uniform event consumption using push-based models. It is designed to handle high volumes of events and can scale automatically to match the volume and size of the incoming event stream. Event Grid also supports popular messaging protocols and technologies like Webhooks, Event Hubs, and Service Bus. You can also use Azure Event Hubs, a big data streaming platform and event ingestion service. Whereas Azure Functions is a serverless compute service that lets you run code on-demand without having to explicitly provision or manage infrastructure. Microsoft also provides support for Kafka as a fully managed service with HDInsight that provides a simplified configuration process and management.

Google Cloud Platform

Google Cloud Platform provides Eventarc, a managed event router service that delivers your events to the right places with minimal configuration. Eventarc connects GCP services, SaaS applications, and on-premises systems with each other using Cloud Events—a uniform open format for describing event data. You can also use Google Cloud Pub/Sub, a distributed messaging service that allows you to decouple systems and components hosted on Google Cloud Platform or elsewhere. It offers reliable and fast message delivery at scale. Google Cloud Functions is a serverless computing service that lets you run code on-demand without having to provision or manage infrastructure.

These three options are just a few available choices for building event-driven platforms in the cloud. Each has its own advantages and disadvantages and requires knowledge of the specific cloud platform to set up and operate properly.

Still, you can also approach EDA implementation by choosing a hybrid strategy or selecting multiple cloud providers.

Hybrid and Multicloud Strategy

EDA enables both hybrid and multicloud strategies and can span across different providers and geographies. A multicloud strategy can provide greater flexibility, resiliency, and cost savings. In many cases, you might not be able to move everything to the cloud, and you will need to keep a combination of on-premise, private cloud, and cloud services. In this case, you can look at Confluent Platform for hybrid and multicloud strategies. Confluent Cloud works as a fully managed Kafka service that allows you to take advantage of the features and services offered by different cloud providers and your on-prem needs. By using a multicloud approach, you can also avoid vendor lock-in and have more flexibility in how you deploy your applications.

Modern Service Infrastructure for Complex Event Processing

Modern service infrastructure is required to process the large volume and variety of events generated by today’s software applications. This infrastructure must be able to handle high throughput, scale elastically, and provide low-latency event processing.

An event-driven architecture can provide the foundation for such an infrastructure. When designed and implemented correctly, event-driven architectures are responsive, scalable, and resilient. They can help you build more efficient and effective software applications.

However, designing and implementing an event-driven architecture is not a trivial task. It requires careful planning and a deep understanding of the system requirements. In addition, it demands knowledge of distributed systems principles and patterns as well as experience with specific technologies and tools.

If you are looking for help setting up an event-driven architecture, nexocode is here to assist. Our experts can work with you to plan and design an architecture that meets your specific needs and scales to handle the ever-growing volume of events. Contact us today to learn more about how we can help.

About the author

Wojciech Gębiś

Wojciech Gębiś

Project Lead & DevOps Engineer

Linkedin profile Twitter Github profile

Wojciech is a seasoned engineer with experience in development and management. He has worked on many projects and in different industries, making him very knowledgeable about what it takes to succeed in the workplace by applying Agile methodologies. Wojciech has deep knowledge about DevOps principles and Machine Learning. His practices guarantee that you can reliably build and operate a scalable AI solution.
You can find Wojciech working on open source projects or reading up on new technologies that he may want to explore more deeply.

Would you like to discuss
AI opportunities in your
business?

Let us know and Mateusz
will arrange a call with our experts.

Thanks for the message!

We'll do our best to get back to you
as soon as possible.

This article is a part of

Becoming AI Driven
19 articles

Becoming AI Driven

Artificial Intelligence solutions are becoming the next competitive edge for many companies within various industries. How do you know if your company should invest time into emerging tech? How to discover and benefit from AI opportunities? How to run AI projects?

Follow our article series to learn how to get on a path towards AI adoption. Join us as we explore the benefits and challenges that come with AI implementation and guide business leaders in creating AI-based companies.

check it out

More articles

Becoming AI Driven

Insights on practical AI applications just one click away

Sign up for our newsletter and don't miss out on the latest insights, trends and innovations from this sector.

Done!

Thanks for joining the newsletter

Check your inbox for the confirmation email & enjoy the read!

Find us on

Need help with implementing AI in your business?

Let's talk blue circle

This site uses cookies for analytical purposes.

Accept Privacy Policy

In the interests of your safety and to implement the principle of lawful, reliable and transparent processing of your personal data when using our services, we developed this document called the Privacy Policy. This document regulates the processing and protection of Users’ personal data in connection with their use of the Website and has been prepared by Nexocode.

To ensure the protection of Users' personal data, Nexocode applies appropriate organizational and technical solutions to prevent privacy breaches. Nexocode implements measures to ensure security at the level which ensures compliance with applicable Polish and European laws such as:

  1. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (published in the Official Journal of the European Union L 119, p 1); Act of 10 May 2018 on personal data protection (published in the Journal of Laws of 2018, item 1000);
  2. Act of 18 July 2002 on providing services by electronic means;
  3. Telecommunications Law of 16 July 2004.

The Website is secured by the SSL protocol, which provides secure data transmission on the Internet.

1. Definitions

  1. User – a person that uses the Website, i.e. a natural person with full legal capacity, a legal person, or an organizational unit which is not a legal person to which specific provisions grant legal capacity.
  2. Nexocode – NEXOCODE sp. z o.o. with its registered office in Kraków, ul. Wadowicka 7, 30-347 Kraków, entered into the Register of Entrepreneurs of the National Court Register kept by the District Court for Kraków-Śródmieście in Kraków, 11th Commercial Department of the National Court Register, under the KRS number: 0000686992, NIP: 6762533324.
  3. Website – website run by Nexocode, at the URL: nexocode.com whose content is available to authorized persons.
  4. Cookies – small files saved by the server on the User's computer, which the server can read when when the website is accessed from the computer.
  5. SSL protocol – a special standard for transmitting data on the Internet which unlike ordinary methods of data transmission encrypts data transmission.
  6. System log – the information that the User's computer transmits to the server which may contain various data (e.g. the user’s IP number), allowing to determine the approximate location where the connection came from.
  7. IP address – individual number which is usually assigned to every computer connected to the Internet. The IP number can be permanently associated with the computer (static) or assigned to a given connection (dynamic).
  8. GDPR – Regulation 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of individuals regarding the processing of personal data and onthe free transmission of such data, repealing Directive 95/46 / EC (General Data Protection Regulation).
  9. Personal data – information about an identified or identifiable natural person ("data subject"). An identifiable natural person is a person who can be directly or indirectly identified, in particular on the basis of identifiers such as name, identification number, location data, online identifiers or one or more specific factors determining the physical, physiological, genetic, mental, economic, cultural or social identity of a natural person.
  10. Processing – any operations performed on personal data, such as collecting, recording, storing, developing, modifying, sharing, and deleting, especially when performed in IT systems.

2. Cookies

The Website is secured by the SSL protocol, which provides secure data transmission on the Internet. The Website, in accordance with art. 173 of the Telecommunications Act of 16 July 2004 of the Republic of Poland, uses Cookies, i.e. data, in particular text files, stored on the User's end device.
Cookies are used to:

  1. improve user experience and facilitate navigation on the site;
  2. help to identify returning Users who access the website using the device on which Cookies were saved;
  3. creating statistics which help to understand how the Users use websites, which allows to improve their structure and content;
  4. adjusting the content of the Website pages to specific User’s preferences and optimizing the websites website experience to the each User's individual needs.

Cookies usually contain the name of the website from which they originate, their storage time on the end device and a unique number. On our Website, we use the following types of Cookies:

  • "Session" – cookie files stored on the User's end device until the Uses logs out, leaves the website or turns off the web browser;
  • "Persistent" – cookie files stored on the User's end device for the time specified in the Cookie file parameters or until they are deleted by the User;
  • "Performance" – cookies used specifically for gathering data on how visitors use a website to measure the performance of a website;
  • "Strictly necessary" – essential for browsing the website and using its features, such as accessing secure areas of the site;
  • "Functional" – cookies enabling remembering the settings selected by the User and personalizing the User interface;
  • "First-party" – cookies stored by the Website;
  • "Third-party" – cookies derived from a website other than the Website;
  • "Facebook cookies" – You should read Facebook cookies policy: www.facebook.com
  • "Other Google cookies" – Refer to Google cookie policy: google.com

3. How System Logs work on the Website

User's activity on the Website, including the User’s Personal Data, is recorded in System Logs. The information collected in the Logs is processed primarily for purposes related to the provision of services, i.e. for the purposes of:

  • analytics – to improve the quality of services provided by us as part of the Website and adapt its functionalities to the needs of the Users. The legal basis for processing in this case is the legitimate interest of Nexocode consisting in analyzing Users' activities and their preferences;
  • fraud detection, identification and countering threats to stability and correct operation of the Website.

4. Cookie mechanism on the Website

Our site uses basic cookies that facilitate the use of its resources. Cookies contain useful information and are stored on the User's computer – our server can read them when connecting to this computer again. Most web browsers allow cookies to be stored on the User's end device by default. Each User can change their Cookie settings in the web browser settings menu: Google ChromeOpen the menu (click the three-dot icon in the upper right corner), Settings > Advanced. In the "Privacy and security" section, click the Content Settings button. In the "Cookies and site date" section you can change the following Cookie settings:

  • Deleting cookies,
  • Blocking cookies by default,
  • Default permission for cookies,
  • Saving Cookies and website data by default and clearing them when the browser is closed,
  • Specifying exceptions for Cookies for specific websites or domains

Internet Explorer 6.0 and 7.0
From the browser menu (upper right corner): Tools > Internet Options > Privacy, click the Sites button. Use the slider to set the desired level, confirm the change with the OK button.

Mozilla Firefox
browser menu: Tools > Options > Privacy and security. Activate the “Custom” field. From there, you can check a relevant field to decide whether or not to accept cookies.

Opera
Open the browser’s settings menu: Go to the Advanced section > Site Settings > Cookies and site data. From there, adjust the setting: Allow sites to save and read cookie data

Safari
In the Safari drop-down menu, select Preferences and click the Security icon.From there, select the desired security level in the "Accept cookies" area.

Disabling Cookies in your browser does not deprive you of access to the resources of the Website. Web browsers, by default, allow storing Cookies on the User's end device. Website Users can freely adjust cookie settings. The web browser allows you to delete cookies. It is also possible to automatically block cookies. Detailed information on this subject is provided in the help or documentation of the specific web browser used by the User. The User can decide not to receive Cookies by changing browser settings. However, disabling Cookies necessary for authentication, security or remembering User preferences may impact user experience, or even make the Website unusable.

5. Additional information

External links may be placed on the Website enabling Users to directly reach other website. Also, while using the Website, cookies may also be placed on the User’s device from other entities, in particular from third parties such as Google, in order to enable the use the functionalities of the Website integrated with these third parties. Each of such providers sets out the rules for the use of cookies in their privacy policy, so for security reasons we recommend that you read the privacy policy document before using these pages. We reserve the right to change this privacy policy at any time by publishing an updated version on our Website. After making the change, the privacy policy will be published on the page with a new date. For more information on the conditions of providing services, in particular the rules of using the Website, contracting, as well as the conditions of accessing content and using the Website, please refer to the the Website’s Terms and Conditions.

Nexocode Team