Event Transformation before Target Delivery | Java Backend Developer Master Program

1. Learning Outcomes#

इस chapter के बाद आप:

समझ पाएँगे कि subscriber filtering के बाद और target delivery से पहले event transformation कहाँ होता है।
समझ पाएँगे कि producer को consumer-neutral business event क्यों publish करना चाहिए।
Transformer configuration का purpose समझ पाएँगे।
RAW, WITH_METADATA, और JSONATA transformation modes में सही choice कर पाएँगे।
$events transformation context का basic mental model समझ पाएँगे।
$events.Data के माध्यम से published PutEvents data तक पहुँचने का idea समझ पाएँगे।
JSONata से fields select, rename और target-specific object बनाना समझ पाएँगे।
per-event transformation evaluation का meaning समझ पाएँगे।
missing fields, invalid results और incorrect expressions से होने वाली transformation problems पहचान पाएँगे।
representative events के साथ transformations test करने का practical approach समझ पाएँगे।
dynamic target parameters के लिए JSONata expressions का उपयोग कब useful है, यह समझ पाएँगे।
classic EventBridge rule Input Transformers और subscriber JSONata transformation के बीच conceptual difference समझ पाएँगे।

2. Event Transformation कहाँ Fit होता है?#

सबसे पहले पूरा flow समझते हैं।

मान लीजिए आपका Java Order Service एक OrderCreated event publish करता है।

EventBridge उस event को receive करता है।

फिर subscriber का filter decide करता है:

क्या यह event इस subscriber के लिए relevant है?

अगर event match करता है, उसके बाद target को भेजने से पहले event को transform किया जा सकता है।

English Definition

Event transformation is the delivery-time reshaping of a matched event into the payload or target parameters required by a subscriber target, without changing the event originally published by the producer.

सरल शब्दों में:

Producer ने जो business event publish किया है, उसे बदले बिना target के लिए suitable shape बनाना event transformation है।

Flow को visually देखें:

Visual Diagram80%

Rendering diagram…

इस flow में तीन अलग responsibilities हैं:

Producer business fact publish करता है।
Subscriber filtering decide करता है कि event चाहिए या नहीं।
Transformer decide करता है कि matched event target को किस shape में देना है।

Remember

Filtering और transformation एक ही चीज नहीं हैं। Filtering event को select करता है। Transformation selected event की delivery shape बदलता है।

3. Producer को Consumer-Neutral Event क्यों Publish करना चाहिए?#

मान लीजिए Order Service ने नया order create किया।

Business fact है:

order बनाया गया
उसका एक orderId है
एक customerId है
amount है
status है

Producer का काम इस fact को publish करना है।

Producer को यह सोचकर event नहीं बनाना चाहिए:

Slack को कौन-सा field name चाहिए?
notification service को recipient field चाहिए या customerId?
analytics system को कौन-सा compact payload चाहिए?
किसी target को metadata चाहिए या नहीं?

English Definition

A consumer-neutral business event describes what happened in the business domain without being shaped for one specific downstream consumer.

इसका मतलब है कि producer business language में event publish करे।

उदाहरण के लिए Java producer का basic publishing code ऐसा हो सकता है:

JAVA

PutEventsRequestEntry entry = PutEventsRequestEntry.builder()
        .source("com.example.orders")
        .detailType("OrderCreated")
        .detail(orderEventJson)
        .eventBusName("orders-bus")
        .build();

यहाँ orderEventJson को business event represent करना चाहिए।

उसे किसी specific target का payload नहीं बनना चाहिए।

गलत design सोच कुछ ऐसी होगी:

Producer कहे:

"Notification consumer को recipient चाहिए, इसलिए मैं अपने main event में recipient add कर देता हूँ।"

कुछ दिन बाद analytics consumer कहे:

"मुझे buyer_id चाहिए।"

फिर producer बदलता है।

फिर तीसरा consumer आता है।

धीरे-धीरे producer का event business event नहीं रहता। वह कई consumers की requirements का मिश्रण बन जाता है।

इसे coupling कहते हैं।

अच्छा design यह है:

Visual Diagram80%

Rendering diagram…

एक ही published business event अलग-अलग subscribers के लिए अलग delivery shape ले सकता है।

यही event transformation का बड़ा architectural फायदा है।

4. Subscriber Transformer Configuration#

English Definition

A subscriber Transformer configuration controls how a matched published event is represented when it is delivered to the subscriber's target.

सरल meaning:

Subscriber filter ने event accept कर लिया।

अब Transformer यह तय करता है कि target को क्या मिलेगा।

इस chapter में तीन important transformation choices हैं:

Mode	कब उपयोग करें	मुख्य idea
`RAW`	target original event data consume कर सकता है	कोई target-specific reshaping नहीं
`WITH_METADATA`	target को event data के साथ metadata भी चाहिए	data + delivery context
`JSONATA`	target को custom payload या dynamic values चाहिए	expression-based transformation

हर case में JSONATA use करना अच्छा design नहीं है।

अगर transformation की जरूरत ही नहीं है, तो unnecessary expression maintain करना complexity बढ़ाता है।

Key Idea

सबसे simple transformation mode चुनें जो target की वास्तविक requirement पूरी करता हो।

5. RAW Transformation#

English Definition

RAW transformation delivers the published event data without applying a target-specific payload transformation.

मान लीजिए downstream application वही event structure समझती है जो producer publish करता है।

उसे:

field rename नहीं चाहिए
fields remove नहीं करने
extra metadata नहीं चाहिए
custom envelope नहीं चाहिए

तो RAW natural choice है।

RAW का Mental Model#

Producer ने event publish किया।

Subscriber ने event match किया।

Target कहता है:

"मुझे यह event जैसा है वैसा ही दो।"

तो unnecessary transformation की जरूरत नहीं है।

RAW कब अच्छा Choice है?#

RAW useful है जब:

producer contract और consumer contract compatible हैं।
consumer original event structure समझता है।
transformation से कोई practical value नहीं मिलती।
simple architecture prefer किया जा रहा है।

RAW कब पर्याप्त नहीं होगा?#

अगर target कहता है:

"मुझे केवल तीन fields चाहिए।"

या:

"मुझे customerId को recipient नाम से चाहिए।"

या:

"मुझे event metadata भी चाहिए।"

तब RAW requirement पूरी नहीं करेगा।

6. WITH_METADATA Transformation#

English Definition

WITH_METADATA delivers event data together with associated metadata required by the target.

कई consumers केवल business payload नहीं चाहते।

उन्हें event के आसपास का context भी useful हो सकता है।

उदाहरण:

auditing
diagnostics
traceability
operational processing
downstream systems जिन्हें event identity या contextual metadata चाहिए

ऐसे target के लिए WITH_METADATA useful हो सकता है।

RAW और WITH_METADATA में Difference#

RAW का focus है:

event data

WITH_METADATA का focus है:

event data + metadata

इसलिए सिर्फ यह सोचकर WITH_METADATA न चुनें कि "more data is better."

Extra metadata तभी भेजें जब target वास्तव में उसका उपयोग करता है।

Common Mistake

हर subscriber को metadata देना flexible design नहीं है। इससे payload बड़ा और consumer contract unnecessarily complex हो सकता है।

7. JSONATA Transformation#

अब सबसे flexible mode देखते हैं।

English Definition

JSONata is a declarative query and transformation language that can select, compute, rename, and construct JSON data.

Subscriber transformation में इसका purpose है:

matched event से target-specific output बनाना।

Producer का original event unchanged रहता है।

Target के लिए नया delivery representation बनता है।

Simple Example#

मान लीजिए published event detail में ये business fields हैं:

Field	Example Meaning
`orderId`	order identifier
`customerId`	customer identifier
`totalAmount`	order amount
`status`	order status

लेकिन notification target को केवल यह चाहिए:

Target Field	Source
`id`	`orderId`
`recipient`	`customerId`
`amount`	`totalAmount`

JSONata expression target-specific object construct कर सकता है:

JSON

{
  "id": $events.Data.Detail.orderId,
  "recipient": $events.Data.Detail.customerId,
  "amount": $events.Data.Detail.totalAmount
}

ध्यान दें कि producer का event नहीं बदला।

Transformation केवल target delivery के लिए नया object बना रहा है।

8. `$events` Transformation Context#

English Definition

The $events transformation context provides the event-related data available to a subscriber transformation expression.

सरल भाषा में:

JSONata expression को कुछ input चाहिए।

उसे current matched event के बारे में जानना पड़ता है।

$events वही transformation context देता है।

इस chapter में सबसे important branch है:

$events.Data

इसका उपयोग published event data तक पहुँचने के लिए किया जाता है।

Context में event-related metadata और system-generated metadata भी transformation के लिए available हो सकते हैं।

Producer को ऐसे system context को अपने business payload में manually duplicate करने की जरूरत नहीं होनी चाहिए।

9. `$events.Data` और PutEvents Payload#

जब producer EventBridge को PutEvents के माध्यम से event publish करता है, तो publishing entry में fields हो सकते हैं जैसे:

Source
DetailType
Detail
event-related additional fields जहाँ applicable हों

Subscriber transformation में $events.Data published event data तक पहुँचने का starting point देता है।

उदाहरण के लिए:

JSON

$events.Data.Source

यह event source तक पहुँचने का expression है।

इसी तरह:

JSON

$events.Data.DetailType

event type information select कर सकता है।

और structured detail से business field चाहिए तो expression इस तरह conceptually navigate कर सकता है:

JSON

$events.Data.Detail.orderId

यहाँ important चीज syntax याद करना नहीं है।

Mental model याद रखें:

$events → current transformation context

$events.Data → published event data

उसके आगे path → required field

10. Published Data, Metadata और System Metadata#

Transformation करते समय तीन तरह की information को अलग सोचें।

1. Published Business Data#

यह producer द्वारा publish किया गया business information है।

उदाहरण:

orderId
customerId
totalAmount
status

इस data का owner producer contract है।

2. Event Metadata#

यह event के बारे में contextual information है।

ऐसा metadata auditing, routing या target integration में useful हो सकता है।

3. System Metadata#

कुछ context system द्वारा generate या maintain किया जाता है।

ऐसी information business payload का हिस्सा बनाना हमेशा सही नहीं होता।

Key Idea

Business data और delivery/system metadata को अलग responsibilities की तरह सोचें। इससे event contract साफ रहता है।

11. JSONata से Field Select करना#

Target को पूरा event नहीं चाहिए तो केवल required field select की जा सकती है।

उदाहरण:

JSON

$events.Data.Detail.orderId

यह expression सिर्फ orderId value select करता है।

यह useful हो सकता है जब कोई target parameter सिर्फ एक value चाहता है।

12. JSONata से Fields Rename करना#

Suppose producer field है:

customerId

लेकिन target contract कहता है:

recipient

Producer को rename करने की जरूरत नहीं है।

Transformation target-specific name बना सकता है:

JSON

{
  "recipient": $events.Data.Detail.customerId
}

इसका मतलब:

Producer अभी भी customerId publish करता है।

लेकिन target को recipient मिलता है।

इससे producer target-specific vocabulary से independent रहता है।

13. Multiple Fields से Target-Specific Object बनाना#

मान लीजिए target को compact notification payload चाहिए।

हम object बना सकते हैं:

JSON

{
  "order": $events.Data.Detail.orderId,
  "customer": $events.Data.Detail.customerId,
  "amount": $events.Data.Detail.totalAmount,
  "state": $events.Data.Detail.status
}

इसमें चार important operations हो रहे हैं:

fields select किए गए।
कुछ fields rename किए गए।
unnecessary fields omit किए गए।
target के लिए नया JSON object construct किया गया।

Original published event फिर भी unchanged है।

Remember

Transformation का output consumer contract है। Published event producer contract है। दोनों को unnecessary तरीके से एक ही contract मत बनाइए।

14. एक Event पर Transformation कैसे Evaluate होता है?#

English Definition

Per-event transformation evaluation means that the transformation expression is evaluated using the context of each matched event being delivered.

मान लीजिए तीन OrderCreated events आए:

Order A
Order B
Order C

Transformer किसी shared hard-coded order पर नहीं चलता।

हर matched event के context से expression evaluate होता है।

Visual Diagram80%

Rendering diagram…

यानी Order A का $events.Data Order A से संबंधित होगा।

Order B के लिए expression फिर evaluate होगा।

इसलिए transformation logic को event-specific और deterministic रखना आसान होता है।

15. Transformation Failure कैसे हो सकता है?#

Transformation powerful है, लेकिन expression गलत assumptions करे तो delivery problem हो सकती है।

Case 1: गलत Path#

आप expression लिखते हैं:

JSON

$events.Data.Detail.customer.email

लेकिन actual event में customer.email मौजूद ही नहीं है।

Expression expected value नहीं दे पाएगा।

Case 2: Optional Field Missing#

मान लीजिए campaignCode optional है।

आप हर event में उसे mandatory मान लेते हैं।

कुछ events में field absent होगा।

Result target के required contract के अनुसार invalid हो सकता है।

Case 3: Wrong Type Assumption#

आप मानते हैं कि कोई field number है।

लेकिन representative event में वह string आता है।

Target-specific expression का result expected shape से अलग हो सकता है।

Case 4: Invalid Expression#

JSONata syntax itself incorrect हो सकता है।

ऐसा configuration या evaluation stage पर problem create कर सकता है।

Case 5: Valid Expression, Invalid Target Result#

Expression syntactically valid हो सकता है, लेकिन generated object target की requirement पूरी नहीं करता।

उदाहरण:

Target requires recipient.

Expression output में recipient missing है।

Technically expression evaluate हो सकता है, लेकिन integration logically broken है।

Warning

केवल expression syntax test करना पर्याप्त नहीं है। Final transformed payload और target-required parameters भी validate करें।

16. Missing Values के बारे में सही Design#

Beginners अक्सर सोचते हैं:

"अगर field कभी-कभी missing है, तो producer में कोई dummy value डाल देते हैं।"

यह हमेशा अच्छा solution नहीं है।

पहले पूछें:

field वास्तव में business event में mandatory है?
या वह केवल एक specific target के लिए optional requirement है?
transformation missing value को safely handle कर सकता है?
target contract को redesign करना चाहिए?

Producer contract को सिर्फ transformation आसान बनाने के लिए pollute नहीं करना चाहिए।

17. Representative Events से Transformation Testing#

Production event transformation के लिए केवल एक perfect sample test करना dangerous है।

कम से कम अलग event shapes test करें।

Test Case	क्या Check करें
Normal event	expected payload बनता है
Optional field present	field correctly transform होती है
Optional field absent	output valid रहता है
Different valid values	hard-coded assumption नहीं है
Boundary values	type और formatting सही है
Unexpected data shape	failure clearly detectable है

अच्छा Testing Sequence#

Realistic producer event लें।
Subscriber filter match confirm करें।
Transformer expression evaluate करें।
Generated payload inspect करें।
Required target fields verify करें।
Optional fields missing करके test करें।
अलग representative event फिर test करें।
Target parameter expressions भी separately verify करें।

Tip

Transformation test में केवल "expression ran successfully" नहीं देखना है। यह देखना है कि "target को exactly usable data मिला या नहीं."

18. Dynamic Target Parameters में JSONata#

JSONata केवल target body बनाने के लिए useful नहीं है।

कुछ target configurations में target parameter भी event data से derive करना useful हो सकता है।

उदाहरण:

मान लीजिए grouping या routing-related parameter customer के आधार पर बनाना है।

Expression हो सकता है:

JSON

$events.Data.Detail.customerId

अब हर event के लिए value dynamically current event से आएगी।

इसका फायदा:

hard-coded value नहीं
producer target configuration नहीं जानता
routing/delivery behavior subscriber side पर रहता है

लेकिन dynamic parameters के साथ एक rule बहुत important है:

Remember

जिस field पर target parameter depend करता है, उसके missing या invalid होने के case को test करना जरूरी है।

19. Transformation और Filtering को Mix मत करें#

मान लीजिए subscriber केवल high-value orders चाहता है।

यह question है:

यह event subscriber के लिए relevant है या नहीं?

यह filtering responsibility है।

अब target कहता है:

"मुझे केवल orderId और totalAmount चाहिए।"

यह question है:

Matched event target को किस shape में देना है?

यह transformation responsibility है।

इस distinction से architecture साफ रहती है।

Filtering:

event selection

Transformation:

delivery representation

20. Classic Custom Event Bus Input Transformers#

EventBridge के traditional rule-based model में classic Input Transformer concept भी मौजूद है।

English Definition

A classic EventBridge rule input transformer extracts values from a matched event and places them into a target input template.

इस model में commonly:

paths define किए जाते हैं
selected values निकाले जाते हैं
target InputTemplate बनाया जाता है

Subscriber-side JSONATA transformation related problem solve करता है, लेकिन configuration model और expression style को identical नहीं मानना चाहिए।

Compatibility Awareness#

अगर existing system classic EventBridge rules use करता है, तो migration या mixed architecture में यह assumption मत करें:

"Input Transformer expression copy करके JSONata में डाल दूँगा।"

दोनों का उद्देश्य payload shaping हो सकता है।

लेकिन syntax और configuration approach अलग हो सकते हैं।

Common Mistake

Classic rule Input Transformer और JSONata subscriber transformer को एक ही syntax समझना integration bugs का कारण बन सकता है।

21. Java Backend Architecture Example#

मान लीजिए हमारे पास:

Order Service
Notification target
Audit target
Analytics target

Order Service consumer-neutral event publish करता है।

Event detail में business information है।

Notification subscriber:

JSONata से छोटा notification payload बनाता है।

Audit subscriber:

event data के साथ metadata चाहता है।

Analytics subscriber:

अपनी analysis requirements के अनुसार selected fields लेता है।

Flow:

Visual Diagram80%

Rendering diagram…

इस design में Order Service को downstream systems के payload contracts maintain नहीं करने पड़ते।

यही loose coupling का practical फायदा है।

22. कौन-सा Mode चुनें?#

Decision को simple रखें।

Target original event consume कर सकता है?#

RAW consider करें।

Target को original data के साथ metadata चाहिए?#

WITH_METADATA consider करें।

Target को selected, renamed, computed या custom-shaped data चाहिए?#

JSONATA consider करें।

Target-specific requirement producer में डालनी पड़ रही है?#

पहले देखें कि subscriber transformation से coupling avoid हो सकती है या नहीं।

23. Common Mistakes#

Mistake 1: हर चीज के लिए JSONATA#

Flexible होने का मतलब यह नहीं कि हर target पर complex expression लिखें।

Simple target के लिए RAW बेहतर हो सकता है।

Mistake 2: Consumer Requirement Producer में डालना#

Producer event में slackMessage, emailRecipient, या consumer-specific names add करना coupling बढ़ा सकता है।

Mistake 3: केवल Happy Path Test करना#

Optional fields और different valid payloads test किए बिना transformation production में fail हो सकती है।

Mistake 4: Filtering को Transformation समझना#

Filter decides whether event चाहिए।

Transformer decides how target को event देना है।

Mistake 5: Metadata हमेशा Include करना#

अगर target metadata use नहीं करता, unnecessary metadata target contract को complex बना सकती है।

Mistake 6: Missing Field को Ignore करना#

Expression किसी path पर depend करता है तो missing-value scenario test करें।

Mistake 7: Classic Input Transformer Syntax को JSONata समझना#

दोनों related use cases solve कर सकते हैं, लेकिन configuration model अलग है।

24. Interview Preparation#

Why should an EventBridge producer publish consumer-neutral business events?Show Answer

A producer should publish events that describe business facts rather than the payload format required by one specific consumer. Target-specific transformation can then be performed at the subscriber or delivery boundary. This reduces coupling and allows multiple consumers to use the same business event independently.

Key Points:

Producer owns the business event contract.
Consumer-specific formatting belongs near the consumer.
Transformation helps reduce producer-to-consumer coupling.
Multiple targets can derive different payloads from the same event.

Why interviewer asks this:

The interviewer wants to know whether you understand event-driven architecture beyond simply calling PutEvents.

What is the difference between RAW, WITH_METADATA, and JSONATA transformation modes?Show Answer

RAW is appropriate when the target can consume the event data without target-specific reshaping. WITH_METADATA is useful when the target needs event data together with relevant metadata. JSONATA is used when the subscriber must select, rename, derive, or construct a target-specific payload or dynamic parameter.

Key Points:

RAW minimizes transformation complexity.
WITH_METADATA adds contextual metadata.
JSONATA provides declarative payload shaping.
Choose the simplest mode that satisfies the target.

Why interviewer asks this:

The interviewer is testing whether you can choose an integration design based on requirements rather than automatically using the most flexible option.

How would you safely test an EventBridge JSONata transformation?Show Answer

I would test the transformation with representative events rather than only a happy-path sample. I would verify field paths, optional and missing fields, data types, generated target payloads, and dynamic target parameters. I would also confirm that the transformed result satisfies the target contract.

Key Points:

Use realistic event samples.
Test missing optional fields.
Validate output shape.
Validate dynamic parameters.
Do not treat expression success alone as end-to-end correctness.

Why interviewer asks this:

The interviewer wants to see whether you think about runtime data variability and integration reliability.

25. Recap#

इस chapter से सबसे important बातें:

Event transformation subscriber filtering के बाद और target delivery से पहले target-specific shaping करता है।
Producer को consumer-neutral business event publish करना चाहिए।
RAW तब useful है जब target original data consume कर सकता है।
WITH_METADATA तब useful है जब target को event data के साथ metadata चाहिए।
JSONATA selected fields, renamed fields और custom target objects बना सकता है।
$events transformation context current event की information देता है।
$events.Data published event data तक पहुँचने का important path है।
Transformation प्रत्येक matched event के context में evaluate होती है।
Missing fields और invalid output assumptions को representative test events से verify करना जरूरी है।
Dynamic target parameters भी event data से derive किए जा सकते हैं जहाँ target configuration इसे उपयोग करती है।
Classic rule Input Transformers और subscriber JSONata transformation related हैं, लेकिन उनका configuration model interchangeable नहीं है।
Target-specific payload requirement के कारण producer contract को unnecessary रूप से बदलना avoid करें।

Printing is unavailable

1. Learning Outcomes#

2. Event Transformation कहाँ Fit होता है?#

3. Producer को Consumer-Neutral Event क्यों Publish करना चाहिए?#

4. Subscriber Transformer Configuration#

5. RAW Transformation#

RAW का Mental Model#

RAW कब अच्छा Choice है?#

RAW कब पर्याप्त नहीं होगा?#

6. WITH_METADATA Transformation#

RAW और WITH_METADATA में Difference#

7. JSONATA Transformation#

Simple Example#

8. $events Transformation Context#

9. $events.Data और PutEvents Payload#

10. Published Data, Metadata और System Metadata#

1. Published Business Data#

2. Event Metadata#

3. System Metadata#

11. JSONata से Field Select करना#

12. JSONata से Fields Rename करना#

13. Multiple Fields से Target-Specific Object बनाना#

14. एक Event पर Transformation कैसे Evaluate होता है?#

15. Transformation Failure कैसे हो सकता है?#

Case 1: गलत Path#

Case 2: Optional Field Missing#

Case 3: Wrong Type Assumption#

Case 4: Invalid Expression#

Case 5: Valid Expression, Invalid Target Result#

16. Missing Values के बारे में सही Design#

17. Representative Events से Transformation Testing#

अच्छा Testing Sequence#

18. Dynamic Target Parameters में JSONata#

19. Transformation और Filtering को Mix मत करें#

20. Classic Custom Event Bus Input Transformers#

Compatibility Awareness#

21. Java Backend Architecture Example#

22. कौन-सा Mode चुनें?#

Target original event consume कर सकता है?#

Target को original data के साथ metadata चाहिए?#

Target को selected, renamed, computed या custom-shaped data चाहिए?#

Target-specific requirement producer में डालनी पड़ रही है?#

23. Common Mistakes#

Mistake 1: हर चीज के लिए JSONATA#

Mistake 2: Consumer Requirement Producer में डालना#

Mistake 3: केवल Happy Path Test करना#

Mistake 4: Filtering को Transformation समझना#

Mistake 5: Metadata हमेशा Include करना#

Mistake 6: Missing Field को Ignore करना#

Mistake 7: Classic Input Transformer Syntax को JSONata समझना#

24. Interview Preparation#

25. Recap#

8. `$events` Transformation Context#

9. `$events.Data` और PutEvents Payload#