Why should you care?

Tight HTTP chains between services create outages. Events decouple checkout from email, analytics, and inventory.

See it live — copy this example

Open mongosh or MongoDB Compass, select database nosqlverse, then run the example. Change one field and run again.

// Persist then emit (app-level) OR watch changes
db.orders.insertOne({ _id: ObjectId("64d000000000000000000001"), status: "placed", total: 1999 })
// Change stream worker:
const cs = db.orders.watch([{ $match: { operationType: "insert" } }])
// on event → publish to Kafka/SQS → email service sends receipt
db.orders.updateOne({ _id: ObjectId("64d000000000000000000001") }, { $set: { status: "paid" } })

Run Example »

Edit the code below and click Run to see the result in Toolliyo’s live editor.

What happened?

• The order document is the source of truth.
• A worker watching inserts triggers downstream work.
• Status updates can emit further events.
• MongoDB does not replace Kafka, but change streams are a solid spine for many designs.

Practice next

1. Insert an order and consume the change event in a script.
2. On insert, write to a local outbox collection for reliability.
3. Update status and handle update events separately.
4. Add an outbox collection { eventId, type, payload, published: false }.
5. Filter watch to status updates only.

Remember

Store state in Mongo; broadcast events. Change streams or outbox patterns connect systems. Idempotent consumers are mandatory.

OrderPlaced fan-out

One insert notifies inventory, invoice PDF, and analytics.

Outcome: Checkout stays fast while side effects run asynchronously.