Atharv Ketkar

API initiated and event driven

Currently learning about system designing and Got to know that you can set things in motion in software either by APIs or something known as event-driven architecture.

In API orchestrated architecture, you have a central entity that is overlooking the whole thing, kind of like an opera master.

When you’re orchestrating something complex and there are a lot of services involved, event-driven architecture can be good because each service can declare that “Hey, I am done with it,” and then when other services are listening to it, it can carry on that way. You can just say “If that microservice’s status is X then go ahead and do it.”

in both API orchestrated and event-driven things you need to have proper sequencing, but I think the decentralized nature of event-driven architecture can make things easier. If you have proper sequencing and EDM potency, then event-driven can be easier to code via AI. If Service B goes down temporarily, events can be queued and processed when it comes back up. With pure API orchestration, you’d need complicated retry logic.

So instead of sequentially writing a piece of code as a chain of API calls and responses, I think having our little process start with an API request and then going forward using event-driven architecture can be good.

And at the end, you can just send a deliverable using an API.

But I think API orchestrated system you are operating a railroad kind of system. You can exactly find where the railroad track was damaged. There is a trail of crumbs to follow.

But in a complex event-driven architecture, if one event is going to activate 2-3 things, that can be a bit complex to trace back. The branching can be hard to trace. But never mind. Seems too complex.

Just got to know about the Saga , and here is what AI is saying about it:

Saga = Booking a trip

You need to:

  1. Book a flight
  2. Book a hotel
  3. Charge your credit card

These are three separate companies/systems. If the hotel booking fails AFTER you’ve already booked the flight and charged the card, you need to undo those.

Choreography (Event-driven):

Flight system: Books seat → publishes "FlightBooked"
Hotel system: Sees "FlightBooked" → books room → publishes "HotelBooked"  
Payment system: Sees "HotelBooked" → charges card → publishes "PaymentDone"

If hotel booking fails:

Hotel system: publishes "HotelFailed"
Flight system: Sees "HotelFailed" → cancels your seat

No central controller. Each system reacts to events.

Orchestration (API-driven):

Trip Coordinator:
  1. Calls Flight API → books seat ✓
  2. Calls Hotel API → tries to book → FAILS ✗
  3. Calls Flight API again → cancels the seat

One coordinator controls everything and knows exactly what happened.

Your hybrid:

"StartBooking" event
↓
Flight Service hears it → calls airline API → gets confirmation → publishes "FlightBooked"
↓  
Hotel Service hears it → calls hotel API → gets confirmation → publishes "HotelBooked"

Events connect the services, APIs do the actual work.

Saga Pattern: One Clarification

In your example, both choreography and orchestration can use either events OR APIs. The real difference is:

  • Choreography = No central brain, services react to each other
  • Orchestration = One service controls the sequence

You can have:

  • Orchestration with events (orchestrator publishes commands, waits for results)
  • Choreography with APIs (services call each other directly based on state changes)

When to Use What?

Use orchestration when:

  • The workflow is complex and changes frequently
  • You need clear visibility into the process
  • You’re okay with one service knowing about many others

Use choreography when:

  • Services should remain loosely coupled
  • The workflow is stable
  • You want maximum resilience (no single point of failure)

Use your hybrid when:

  • You need synchronous responses to users
  • But want async processing internally
  • You want the best of both worlds