In this article, you’ll learn the foundations of event-driven APIs, how they interact with consumers, the technology choices to build them, and how to document them with AsyncAPI specification.
We, as information consumers, have a craving desire to know things as they happen.
Where is my package right now? What’s the score of the game? How is Dogecoin performing today? Likewise, the list goes on. A majority of Internet users today would like information to be pushed towards them rather than pulling.
Microservices architectures are inherently distributed. Building Microservices always bring in the most challenging problems, such as resilient service invocation, distributed transactions, on-demand scaling, and exactly-once processing of messages.
Putting Microservices on Kubernetes doesn’t always solve these problems as Kubernetes doesn’t have an application logic. Frameworks like Spring Boot, Akka, and Quarkus offered great help when building distributed Microservices architectures. But they are tightly coupled to specific programming languages and often opinionated.
So developers remain searching for a portable runtime to build distributed, scalable, and event-driven Microservices.
Dapr is a portable, event-driven runtime that makes it easy for any developer to…
This post serves as an introduction to the Change Data Capture (CDC) practice, rather than a deep-dive on a particular tool. First, I will explore the motivation behind CDC and illustrate the components of a real-time event-driven CDC system. The latter parts discuss some potential use cases where CDC is applicable and conclude with some open-source tools available in the market.
P.S I made a YouTube videos for this post to explain this visually as well. If you are interested, you can check it below.
Applications start with a small data footprint. Initially, a single database fulfils every data…
Operational data accumulated in OLTP databases often need to be taken out to perform useful tasks other than transaction processing. That includes moving data out to data warehouses, updating caches, dashboards, etc.
Change Data Capture (CDC) is the process of observing all data changes written to a database and extracting them in a form in which they can be replicated to downstream systems for other purposes.
In this article, I discuss some real-world use cases where CDC is applicable. Most of the examples are related to Debezium, on open-source CDC engine built on top of Kafka.
If you are new…
We, as consumers, are daily users of credit cards. But, unfortunately, sometimes our buying behaviors drive the credit card to its limit without making us aware. So it would be nice to have my credit card company gives me a friendly warning when my total spend reaches certain thresholds of my credit limit.
That kind of warning makes me aware of my spending habits and makes…
DynamoDB provides two Change Data Capture (CDC) approaches to capture changes from a table. In this post, I’ll introduce you to DynamoDB streams as a reliable CDC mechanism, how it works, and what ways you can consume change events from it.
Imagine your application inserts an entry (a user object) into a DyanmoDB table. A Lambda function is interested in processing that record to send the new user a welcome email.
How would you implement that?
There are two options:
In this article, I’ll introduce you to Debezium, how it is made of and walk you through a practical example to see it in action. Unlike my other articles, I’ve added a bit of visual flair to make it more engaging.
As a primer to this, I suggest you read my previous article on Change Data Capture(CDC).
Real-time applications are becoming increasingly popular in the new digital economy.
Unless your application doesn’t push information to users, they might not engage with it, and maybe they will forget it eventually. That’s why every application you see today tries to send you notifications.
It’s a subtle way of telling, “Dear user, please use me today.”
However, building such applications is challenging. But some serverless platforms make it painless for you. This post discusses them in detail.
For a primer on event-driven APIs and how real-time applications work, you can refer to my article below.
Today, we can see many…
When a consumer receives a message from the broker, the consumer decides what to do with the message.
The consumer can make different decisions here. For example, the processing was successful, and the message can be deleted from the queue. Perhaps, the message violates business rules, so that it should go into the dead letter queue. Maybe, it is not the right time to process the message, so the consumer decides to defer the processing.
Whatever the action had been taken on the message, the consumer must communicate that to the broker to maintain a reliable processing guarantee.
Azure Service Bus is a managed message queueing service offered by Microsoft Azure. In Azure Service Bus, you can schedule a message to deliver at a later time.
This post discusses how to schedule a message, cancel a scheduled message, and browse already scheduled messages with Azure Service Bus and its .NET SDK client.
In messaging, you can send a message to a queue/topic for delayed processing. Those messages are called scheduled messages.
Unlike regular messages, scheduled messages don’t appear in the queue until the defined enqueue time. For example, you can schedule a message at 12 pm and send…