This week’s issue brings you:

• Understanding Event-Driven Systems

• GraphQL vs REST (Recap)

• How Do DDoS Attacks Work, And How Do We Prevent Them (Recap)

• SSL vs TLS — What’s the Difference? (Recap)

READ TIME: 6 MINUTES

Understanding Event-Driven Systems

Quite a lot of the tasks modern-day systems are required to do are in response to changes in state.

Adding an item to a shopping cart, liking a post, and paying a bill are all state changes that trigger a set of tasks in their respective systems.

This requirement has paved the way for a popular approach to system architecture known as event-driven architecture (EDA).

There are four main components in an event-driven architecture — events, producers, consumers, and channels.

In a nutshell, events are updates to the system’s state which are generated by producers. When an event occurs, it is sent to consumers via channels which will then trigger processes or actions.

In more detail.

Events represent changes or updates to the system's state. These can range from a user action, like clicking a button, to a system-generated alert, such as a threshold being reached.

Producers are the sources of events. They monitor the system's state for specific changes or conditions and generate an event when such a change occurs. Producers can be anything from a user interface to a sensor or a service within the system.

Consumers are the recipients of the events. They listen for events they are interested in and, upon receiving such an event, perform a corresponding action or process. This decoupled nature allows consumers to operate independently from the producers, enhancing the system's modularity and flexibility.

Channels serve as the conduits between producers and consumers. They ensure the reliable delivery of events from producers to consumers. They often support different message distribution patterns, such as broadcasting to multiple consumers or directing messages to a specific recipient.

Synchronous vs Asynchronous Event Handling

Events can be handled synchronously or asynchronously.

When using a synchronous approach, the producer would need to wait for the consumer to process the event before moving on to the next task.

For example, when booking a hotel online your web browser would wait for the system to complete your request and return a result before it can proceed.

Synchronous processing provides a predictable execution path for every given event, which makes it far simpler to understand and debug.

It is necessary in scenarios where an immediate response is critical, such as processing financial transactions.

However, its rigid nature makes it incompatible with components that generate high amounts of events or carry out time-consuming processing operations.

Synchronous processing limits the system's scalability and fault tolerance which is why it should only be reserved for when it is absolutely necessary.

On the other hand, asynchronous processing doesn't wait for a response. Producers queue up events for consumers to process and then move on to the next task.

For example, posting a status update on social media does not need immediate action. Instead, your followers can be notified asynchronously.

Asynchronous processing is more commonly used in event-driven architecture because it promotes scalability, loose coupling, resilience, and flexibility better than a synchronous approach.

It is ideal in scenarios where events are generated frequently and in large portions, which is generally the case for most systems built with an event-driven design.

Race conditions are the most notable pitfall to asynchronous processing, this is often best solved with well-designed queues.

The Upside of Event-Driven Architecture

EDA stands out for its scalability, efficiency, and flexibility.

By decoupling services, it seamlessly handles fluctuating demands, fostering system growth with minimal overhaul.

EDA's event-centric approach ensures resources are used only when necessary, enhancing efficiency. Its loosely coupled design allows components to evolve independently, simplifying updates and maintenance while boosting system resilience and adaptability.

This combination of features positions EDA as a popular architecture for developing robust and efficient modern systems.

Challenges of Event-Driven Systems

While there are a lot of upsides to event-driven architecture, it does introduce complexity, especially in managing and monitoring distributed environments.

Scaling exacerbates these challenges, making event flow tracing and error diagnosis difficult without advanced tools and expertise.

Another significant challenge of EDA is its decentralized approach, which complicates data consistency and event ordering, risking data integrity and timely processing.

These challenges require careful implementation and management to fully leverage EDA's benefits.

Where Event-Driven Architecture Shines

EDA shines in scenarios that require real-time responsiveness and scalability across distributed systems. As well as scenarios where events are generated frequently and in large amounts—as the name implies.

Its applicability spans various domains, from IoT, which relies on immediate reaction to sensor data, to real-time data processing systems that must process and analyze data streams with minimal latency.

Microservices also greatly benefit from EDA, as it allows for decoupled services that can independently respond to state changes.

These use cases underscore event-driven architecture’s versatility and ability to enhance system responsiveness and scalability.

Wrapping Up

Event-driven architecture is a scalable and efficient solution for systems that consist of many nodes or services and process large volumes of events. It promotes loose coupling and helps keep the system flexible and simpler to maintain.

GraphQL vs REST (Recap)

Below are some of the main benefits and challenges of REST and GraphQL.

REST

🔷 Scalability: Its stateless nature allows REST services to handle a large volume of requests and horizontally scale with ease.

🔷 Simplicity and flexibility: Leveraging standard HTTP methods, makes it easy to understand and implement.

🔷 Cacheability: By enabling responses to be cached on the client side, REST significantly boosts performance and reduces server load.

🔶 Over-fetching and under-fetching: REST APIs can return excessive data or require multiple calls for complex data.

🔶 Rigid structure: Adhering to RESTful principles can sometimes lead to inflexibility in API design.

GraphQL

🔷 Efficient data loading: Ideal for applications with complex data structures and relationships.

🔷 Single network request: Multiple data needs can be consolidated into a single network request.

🔷 Real-time data with subscriptions: GraphQL supports real-time updates.

🔶 Performance issues with complex queries: Complex queries in GraphQL can sometimes lead to performance problems.

🔶 Caching challenges: Unlike REST, which can easily leverage HTTP caching, GraphQL requires more sophisticated strategies.

See the full post here for more details.

How Do DDoS Attacks Work, And How Do We Prevent Them (Recap)

Distributed Denial of Service (DDoS) attacks are a major threat to digital systems, disrupting traffic to targeted servers, services, or networks, often resulting in financial losses, reputation damage, and diminished user trust.

DDoS attacks inundate a target with traffic from numerous sources, making it difficult to pinpoint and block the bad actors. The multi-source aspect sets DDoS apart from its cousin, the Denial of Service (DoS) attack.

Given the complexity and adaptability of DDoS attacks, it becomes imperative to deploy well-planned defensive measures, such as:

• Embracing redundancy - Distributing network traffic across multiple servers, especially in varied geographical locations, makes it challenging for attackers to bring down your entire system.

• Applying rate limiting - By restricting the number of requests a user can send in a given time frame, rate limiting can halt suspicious spikes in traffic.

• Implementing WAFs - Use Web Application Firewalls to filter HTTP traffic and block harmful patterns.

• Leveraging cloud solutions - Cloud providers offer built-in solutions to help mitigate DDoS attacks.

• Analyzing traffic - Continuously monitor web traffic for anomalies.

For an extended breakdown of DDoS attacks and strategies to prevent them, see here.

SSL vs TLS — What’s the Difference? (Recap)

• SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols designed to provide secure communication over a network.

• TLS is the successor to SSL and has addressed the vulnerabilities present in SSL.

• The process of how data is sent using these protocols involves roughly 8 steps. The most significant differences between these two protocols occur during the key exchange (step 4) and encrypted data transfer (step 7).

• SSL predominantly uses RSA for key exchange, whereas TLS uses other mechanisms like DH (Diffie-Hellman) and ECDH (Elliptic Curve Diffie-Hellman).

• SSL uses older encryption algorithms, some of which are vulnerable. TLS uses updated & more robust encryption algorithms that have overcome the vulnerabilities in SSL.

Check out the full post here for a detailed breakdown of the differences between SSL and TLS.

That wraps up this week’s issue of Level Up Coding’s newsletter!

Join us again next week where we’ll explore designing safe and effective APIs, What is Kafka, and how does it work, and MVC vs MVP.