Welcome to PulseCart: What This Series Is and Who It's For
Day 0 of Building PulseCart: Event-Driven Architecture on GCP
Most event-driven architecture tutorials use a toy example — a few queues, a couple of fake events, a "look it works" demo. That's fine for learning syntax, but it doesn't prepare you for the actual decisions you'll make in production: which GCP service to reach for, how to handle retries when a downstream service is down, or why your event backlog is growing even though nothing looks broken.
This series takes a different approach. We're building PulseCart, a fictional e-commerce and marketing-automation platform, but we're building it the way a real system would need to work at scale. Every architectural decision in this series — Pub/Sub over self-managed message brokers, Cloud Tasks for delayed work, Airflow for batch orchestration — mirrors patterns used in production systems that process millions of events and terabytes of data daily.
What Is PulseCart?
PulseCart is not a real product. It's a teaching vehicle: an e-commerce platform where user behavior (browsing, adding to cart, abandoning a cart, completing a purchase) triggers real-time, personalized messaging — think "you left something in your cart" emails, but architected the way a system handling millions of these events actually needs to be architected.
We picked e-commerce + marketing automation specifically because it naturally needs both halves of event-driven architecture:
Reactive, real-time events — a user adds an item to their cart, and within seconds a personalization engine decides whether to nudge them.
Scheduled, batch-oriented workflows — nightly jobs that aggregate yesterday's behavior, retrain recommendation signals, and reconcile messages that failed to send.
Most tutorials only show you one of these. PulseCart needs both, which is exactly why it's a useful example.
Why GCP-Native Services Instead of Kafka?
If you've looked at event-driven architecture content before, there's a good chance it leaned on Apache Kafka. Kafka is a legitimate and widely-used choice, but it also means standing up and operating a cluster — brokers, partitions, replication, the works.
This series intentionally goes a different direction: Google Cloud's managed services — Pub/Sub, Cloud Tasks, Cloud Run, and Cloud Composer (managed Airflow). The architectural concepts are the same (decoupling, asynchronous processing, at-least-once delivery, retries), but the operational model is different. You're not managing brokers; you're configuring managed infrastructure and writing the services that use it.
This matters because a lot of teams — especially smaller ones, or teams already on GCP — don't need to run their own Kafka cluster to get the benefits of event-driven architecture. Knowing when a managed service is the right call, and what tradeoffs come with it, is itself a production skill worth learning.
Who This Series Is For
This series assumes you're comfortable with:
Building REST APIs (we'll use FastAPI throughout)
Basic cloud platform exposure (you don't need to be a GCP expert, but "I've deployed something to a cloud provider before" helps)
Reading and writing Python
It's not an introduction to programming or to APIs. It's also not a Kafka tutorial — if you specifically want broker-based, self-managed event streaming, that's a different series. This one is for engineers who want to see how to design and operate event-driven systems using managed cloud infrastructure, with the kind of detail that production systems actually require: retry semantics, dead-letter handling, autoscaling, observability — not just "publish a message, see it consumed."
What You'll Build
By the end of this series, you'll have a working pipeline that:
Ingests commerce events through a FastAPI service and publishes them to Pub/Sub
Routes real-time events to Cloud Run consumers that trigger personalized messaging
Uses Cloud Tasks for delayed and retryable workflows (like a cart-abandonment reminder two hours later)
Orchestrates nightly batch jobs with Airflow/Cloud Composer for aggregation and reconciliation
Is provisioned entirely through Terraform, with CI/CD for zero-downtime deploys
Is observable — with monitoring for event backlog, queue depth, and DAG failures, so you know when something's actually wrong
The Roadmap
Here's what each post in the series covers:
Day 1 — Event-Driven Fundamentals: Why request-response breaks down at scale, and PulseCart's event taxonomy
Day 2 — Pub/Sub Topics and Subscriptions: Designing PulseCart's event backbone, push vs. pull subscriptions, dead-letter topics
Day 3 — FastAPI Producer: Publishing commerce events to Pub/Sub, delivery semantics, and idempotency
Day 4 — Cloud Run Consumers and Cloud Tasks: Reactive triggered workflows vs. delayed/scheduled work
Day 5 — Orchestrating Batch Workflows with Airflow: Nightly aggregation, reconciliation, and how this complements the reactive layer
Day 6 — Production Infrastructure: Terraform, autoscaling, and zero-downtime deploys
Day 7 — Observability and Scaling: Monitoring event lag, queue depth, DAG failures, and what breaks at 10x scale
A Quick Note on Where This Comes From
I'm a senior full-stack engineer leading a small engineering team, and a meaningful part of my day-to-day work is designing and operating real-time, event-driven systems — pipelines that process millions of messages and terabytes of data daily, and cloud migrations involving exactly the GCP services this series covers. PulseCart is fictional, but the patterns, failure modes, and tradeoffs in this series aren't hypothetical — they're drawn from building and running these systems in production.
If you're trying to understand event-driven architecture beyond the "hello world" level, I think you'll get real value out of this. Let's get started.
Next up: Day 1 — Event-Driven Fundamentals, and why PulseCart moved off request-response.
