# Exercise 1: EventBridge Rules for an Order Platform

`PetPal`'s `orders` service publishes events to a custom bus `petpal-events`:

```json
{ "source": "petpal.orders", "detail-type": "OrderPlaced",    "detail": { "orderId": "o-1", "total": 12000, "currency": "EUR", "country": "DE", "items": 3, "customerTier": "gold" } }
{ "source": "petpal.orders", "detail-type": "OrderCancelled", "detail": { "orderId": "o-1", "reason": "customer_request" } }
{ "source": "petpal.payments", "detail-type": "PaymentFailed", "detail": { "orderId": "o-2", "attempt": 3 } }
```

## Deliverables

Write each **event pattern** (JSON) and describe the **target** configuration (input transformer, retry policy, DLQ):

1. `fraud-check` (Lambda): `OrderPlaced` with total > 10,000 (cents) OR customerTier = "new".
2. `warehouse-eu` (SQS queue): `OrderPlaced` where country is one of DE, FR, NL, BE.
3. `analytics` (Kinesis Data Firehose → S3): every event from any `petpal.*` source.
4. `support-alerts` (API destination → a Slack webhook): `PaymentFailed` with attempt ≥ 3, transformed to `{"text": "Payment failed 3x for order <orderId>"}`.
5. `loyalty` (Step Functions): `OrderPlaced` from gold customers, but NOT when the order is later cancelled — explain why a single rule can't express "not later cancelled" and how the workflow handles it.
6. **Replay**: the loyalty service had a bug for 3 days; describe how you'd use archive & replay without re-triggering fraud checks and warehouse shipments.
7. **Schedules**: a nightly report at 02:00 Europe/Berlin via EventBridge Scheduler — write the schedule expression and explain why Scheduler is better than a cron rule on the default bus here.

## Requirements Checklist

- [ ] 1 uses `$or` (or two rules) with `{"numeric": [">", 10000]}` and `customerTier: ["new"]`.
- [ ] 2 uses `"country": ["DE","FR","NL","BE"]`.
- [ ] 3 uses `"source": [{"prefix": "petpal."}]`.
- [ ] 4 uses `{"numeric": [">=", 3]}` and an input transformer with `InputPathsMap`/`InputTemplate`; API destination with a connection (auth) and DLQ.
- [ ] 5 explains rules are stateless per event; the workflow waits (e.g. 14-day `Wait` or until return window) and checks order status before awarding points (or listens for cancellation via task token).
- [ ] 6 replays from the archive to a **new rule/bus target** filtered to the loyalty rule only (replay targets specific rules), with idempotent consumers.
- [ ] 7 `cron(0 2 * * ? *)` with time zone `Europe/Berlin` (Scheduler supports time zones, one-off schedules, DLQs, flexible windows).