Event Driven vs API-led Connectivity
Event Driven vs API-led Connectivity¶
What is a REST API?¶
The next few sections have been pulled from 1
REST (Representational State Transfer) is a synchronous communication pattern based on HTTP. It enables clients to send requests and receive responses — often used for CRUD (Create, Read, Update, Delete) operations.
Key Characteristics
- Stateless
- Resource-based
- Follows HTTP standards (GET, POST, PUT, DELETE)
- Easy to develop and debug
Common use cases:
- Fetching user profiles
- Submitting forms
- And scenario needing immediate client feedback
What is Event-Driven Architecture?¶
In an event-driven architecture, services communicate by producing and reacting to events — messages that signify “something happened.”
For example, when a user places an order, it triggers an OrderPlaced event. Multiple consumers (like Payment Service, Notification Service, and Analytics Service) can react to it independently and asynchronously.
Key characteristics
- Asynchronous and decoupled
- Built on events and queues
- Promotes scalability and flexibility
- Needs observability and proper error handling
Common use cases:
- Order processing systems
- Data pipelines
- IoT and streamihng applications
REST vs Event-Driven Architecture¶
| Scenario(s) | REST API | Event-Driven |
|---|---|---|
| Communication Type | Synchronous | Asynchronous |
| Coupling | Tight coupling (client <-> server) | Loose coupling (producer <-> multiple consumers) |
| Complexity | Relatively simple to build and debug | More complex (requires event brokers, monitoring, etc.) |
| Observability | Easier to trace with standard logs | Requires structured event tracing and centralized logging |
| Scalability | Limited by synchronous flow | Scales better with independent service provisioning |
| Best Suited For | CRUD apps, real-time user interaction | Async processing, microservices, decoupled systems |
When to choose what?¶
Choose REST when:
- You need real-time client response
- The system is simple and synchronous
- You're building CRUD-based applications
- Low latency and predictability are important
Choose Event-Driven when:
- Services should be loosely coupled
- You want to scale specific parts of your system
- Tasks happen independently and in parallel
- You're building modern cloud-native microservices
Deciding when to use API-led Connectivity¶
A few points that could help decide which connectivity model would be most appropriate for your integration pattern. However, if the secenario is retreiving data on demand for a user, it will be API-led Connectivity.
When do I use API-led Connectivity?¶
-
Performing any primary actions that need succeed (or fail) before other actions are taken or any other time sensitive actions. Example: Updating payment information, the user needs that done immediately.
-
Systems that don't have the ability to perform Events can use API-led connectivity.
When do I use Event Driven Architecture?¶
-
Event driven in the ideal choice for creating notifications, creating supporting structures (not time sensitive) in the integrated system.
-
C~~R~~UD (Create, Update, Delete) operations are ideal for event driven architecture (not time sensitive).
API-led Connectivity¶
API-led connectivity is the method of integrating applications with reusable APIs that fall within three categories; System, Process, and Experience.
System¶
There is no business process in this layer and the operations provided are consumed from a wide audience — the data returned is agnostic and can be used by all parties. For example, all systems integrating with this layer are requesting order data; what they do with the returned order data is handled at their process or experience layer. Proper authorization needs to be taken into consideration.
Process¶
This layer would provide the largest portion of necessary business process. After the operations are performed against the system layer, if any additional actions need to take place to provide information to the users at the experience layer, this would be the ideal layer. For example, after getting the order data from the system layer, perhaps you are required to; obfuscate data, return a subset of data, or perform operations on portions of the data set. It is at this layer the operations are executed.
Experience¶
The final layer has the most specificity in terms of what the business requires for the end users. The experience layer you are providing to the user is this layer. This is where the final adjustment to how data is presented will take place. For example, do not manipulate a date time for any reason lower than the experience layer; dates will be stored and transferred adhering to the RFC 3339 or ISO-8601 standard.
Diagram of connectivity with layers¶


The two figures above depict that the left side is closer to more core or system logic, and the right side is more user or automated processes. For example, all documents in our document management system will be created (fundamentally) with the same process.
Event Driven Architecture¶
Event driven connectivity is used to provide eventual consistency for the interconnected systems. Operations such as updating customer contact information, or a project creation notification to ensure other interconnected systems have their associated process started or progressed.
Having an event system for updating information in source of truth systems so that system can process the requests when they have the resources and at a pace that does not impact normal operations. Standard data request will not be done via an event system — standard data requests are recommended to be done via API-led connectivity so that caching mechanisms can be used as much as possible in layers where appropriate.
-
https://medium.com/@sneha.agrawal1402/rest-apis-vs-event-driven-architecture-when-to-use-what-d68b25906c05 ↩