Webhook payload design in Rest API - Time & Space Complexity

Time Complexity: Webhook payload design

O(n)

Understanding Time Complexity

When designing webhook payloads, it's important to understand how the size and structure of the data affect processing time.

We want to know how the time to handle a webhook grows as the payload gets bigger or more complex.

Scenario Under Consideration

Analyze the time complexity of the following webhook payload processing code.

POST /webhook
{
  "events": [
    {"id": "1", "type": "update", "data": {...}},
    {"id": "2", "type": "create", "data": {...}},
    ...
  ]
}

for event in payload.events:
  process(event)

This code processes each event in the webhook payload one by one.

Identify Repeating Operations

Look for parts that repeat as the input grows.

• Primary operation: Looping through each event in the payload.
• How many times: Once for every event in the events list.

How Execution Grows With Input

As the number of events increases, the processing time grows in a straight line.

Input Size (n)	Approx. Operations
10	10 process calls
100	100 process calls
1000	1000 process calls

Pattern observation: Doubling the number of events roughly doubles the work done.

Final Time Complexity

Time Complexity: O(n)

This means the processing time grows directly with the number of events in the payload.

Common Mistake

[X] Wrong: "Processing multiple events at once is always constant time because it's one webhook call."

[OK] Correct: Each event still needs individual handling, so more events mean more work and more time.

Interview Connect

Understanding how webhook payload size affects processing helps you design efficient APIs and handle real-world data smoothly.

Self-Check

"What if the payload included nested lists of events inside each event? How would that affect the time complexity?"

Practice

1. What is the main purpose of a webhook payload in a REST API?

easy

A. To store user login credentials securely

B. To create a user interface for the API

C. To send event details from one app to another automatically

D. To encrypt data between client and server

Solution

1. Step 1: Understand webhook payload role

   A webhook payload is a message sent automatically when an event happens, sharing event details.

2. Step 2: Compare options with webhook purpose

   Only To send event details from one app to another automatically describes sending event details automatically, which matches webhook payload use.

3. Final Answer:

   To send event details from one app to another automatically -> Option C

4. Quick Check:

   Webhook payload = event details sent automatically [OK]

Hint: Webhook payloads always send event info automatically [OK]

Common Mistakes:

• Confusing payload with user authentication
• Thinking payload creates UI
• Assuming payload encrypts data

2. Which of the following is the correct JSON structure for a webhook payload that includes event name and timestamp?

easy

A. [ "event": "user_signup", "timestamp": "2024-06-01T12:00:00Z" ]

B. { "event": "user_signup", "timestamp": "2024-06-01T12:00:00Z" }

C. { event = "user_signup", timestamp = "2024-06-01T12:00:00Z" }

D. "event": "user_signup", "timestamp": "2024-06-01T12:00:00Z"

Solution

1. Step 1: Identify valid JSON syntax

   JSON objects use curly braces {}, keys and values separated by colon :, keys in double quotes, and comma between pairs.

2. Step 2: Check each option's syntax

   { "event": "user_signup", "timestamp": "2024-06-01T12:00:00Z" } uses correct JSON object syntax. [ "event": "user_signup", "timestamp": "2024-06-01T12:00:00Z" ] uses square brackets which denote arrays, not key-value pairs. { event = "user_signup", timestamp = "2024-06-01T12:00:00Z" } uses equals sign instead of colon. "event": "user_signup", "timestamp": "2024-06-01T12:00:00Z" is missing braces.

3. Final Answer:

   { "event": "user_signup", "timestamp": "2024-06-01T12:00:00Z" } -> Option B

4. Quick Check:

   Valid JSON object = { "event": "user_signup", "timestamp": "2024-06-01T12:00:00Z" } [OK]

Hint: JSON objects use braces and colons, not brackets or equals [OK]

Common Mistakes:

• Using square brackets instead of braces for objects
• Using equals sign instead of colon
• Omitting braces around JSON

3. Given this webhook payload JSON:

{"event": "order_created", "timestamp": "2024-06-01T15:30:00Z", "data": {"order_id": 123, "amount": 49.99}}

What value will the receiving app find for data.amount?

medium

A. 49.99

B. order_created

C. "amount"

D. 123

Solution

1. Step 1: Locate the data.amount field in JSON

   Inside the "data" object, the key "amount" has the value 49.99 (a number).

2. Step 2: Match the value to options

   49.99 matches the numeric value 49.99. Other options are either keys or unrelated values.

3. Final Answer:

   49.99 -> Option A

4. Quick Check:

   data.amount = 49.99 [OK]

Hint: Look inside nested 'data' object for 'amount' key [OK]

Common Mistakes:

• Confusing order_id with amount
• Selecting string key instead of value
• Choosing event name instead of data field

4. You receive this webhook payload:

{"event": "payment_failed", "timestamp": "2024-06-01T16:00:00Z", "data": {"payment_id": 789}}

What is wrong with this payload?

medium

A. Payment ID should be a string, not a number

B. Timestamp format is incorrect

C. Event name should be inside data object

D. Missing closing brace for the JSON object

Solution

1. Step 1: Check JSON completeness

   The payload ends without a closing brace '}' for the outermost JSON object, making it invalid JSON.

2. Step 2: Verify other parts

   Timestamp format is ISO 8601 and correct. Event name is correctly outside data. Payment ID can be number or string depending on design.

3. Final Answer:

   Missing closing brace for the JSON object -> Option D

4. Quick Check:

   JSON must have matching braces [OK]

Hint: Always check for matching braces in JSON payloads [OK]

Common Mistakes:

• Ignoring missing braces
• Assuming timestamp format is wrong
• Thinking event must be inside data

5. You want to design a webhook payload for a "user_deleted" event that includes the user ID and deletion reason. Which JSON payload design is best for clarity and easy parsing?

hard

A. { "event": "user_deleted", "timestamp": "2024-06-01T17:00:00Z", "data": { "user_id": 456, "reason": "requested by user" } }

B. { "user_deleted": true, "user": 456, "reason": "requested by user" }

C. { "event": "user_deleted", "user_id": 456, "reason": "requested by user" }

D. { "event": "user_deleted", "timestamp": "2024-06-01T17:00:00Z", "user": { "id": 456, "reason": "requested by user" } }

Solution

1. Step 1: Check for standard webhook fields

   { "event": "user_deleted", "timestamp": "2024-06-01T17:00:00Z", "data": { "user_id": 456, "reason": "requested by user" } } includes event name, timestamp, and a nested data object holding user_id and reason, which is clear and standard.

2. Step 2: Compare other options for clarity and parsing

   { "user_deleted": true, "user": 456, "reason": "requested by user" } lacks event and timestamp keys properly named. { "event": "user_deleted", "user_id": 456, "reason": "requested by user" } mixes data fields at root level, less organized. { "event": "user_deleted", "timestamp": "2024-06-01T17:00:00Z", "user": { "id": 456, "reason": "requested by user" } } nests reason inside user object, which is less intuitive.

3. Final Answer:

   { "event": "user_deleted", "timestamp": "2024-06-01T17:00:00Z", "data": { "user_id": 456, "reason": "requested by user" } } -> Option A

4. Quick Check:

   Standard event + timestamp + data object = { "event": "user_deleted", "timestamp": "2024-06-01T17:00:00Z", "data": { "user_id": 456, "reason": "requested by user" } } [OK]

Hint: Use event, timestamp, and data object for clear payloads [OK]

Common Mistakes:

• Omitting timestamp
• Mixing data fields at root level
• Nesting unrelated fields inside user