Skip to content

Latest commit

 

History

History
113 lines (67 loc) · 3.91 KB

File metadata and controls

113 lines (67 loc) · 3.91 KB

Idempotency & Statelessness

1. Idempotency

Definition

  • Idempotency means performing the same operation multiple times produces the same result as performing it once.
  • It ensures safe retries in distributed systems, APIs, and microservices.

Example

Operation Idempotent? Explanation
GET /user/123 ✅ Yes Always returns the same user data (no state change).
DELETE /user/123 ✅ Yes Deleting the same user again has no effect after the first time.
POST /user ❌ No Creates a new user every time — changes system state.
PUT /user/123 ✅ Yes Replaces user data with the same payload every time.

Importance

  • Prevents duplicate side effects (e.g., double payments, double orders).
  • Enables safe retries in case of network or service failures.
  • Makes APIs more reliable and predictable.

How to Implement Idempotency

  1. Idempotency Key:

    • Assign a unique request ID (e.g., idempotency-key: 12345) to ensure repeated requests don’t duplicate actions.
    • Used in payment APIs (like Stripe, PayPal).
  2. State Check Before Action:

    • Check if an operation has already been performed before executing it again.
  3. PUT Instead of POST:

    • Prefer PUT for resource updates since it’s naturally idempotent.
  4. Database Constraints:

    • Use unique constraints (like unique order IDs) to prevent duplicates.

2. Statelessness

Definition

  • A stateless system does not store any information (state) about the client between requests.
  • Each request contains all necessary context to process it.

Example

Stateful System Stateless System
Server stores user session data. Client sends auth token (JWT) in every request.
Load balancer must route user to same server. Any server can handle any request.
Example: Traditional web servers with in-memory sessions. Example: REST APIs, Serverless apps.

Benefits of Statelessness

  • Scalability: Any server can handle any request.

  • Fault Tolerance: No session loss if one server fails.

  • Simplicity: Easier to maintain and scale horizontally.

  • Improved Load Balancing: Traffic can freely move across servers.


Challenges

  • Client Overhead: Client must send all context each time.

  • No Session Persistence: Hard to maintain login state without tokens.

  • Data Re-fetching: Increases network traffic for repeated data.


Best Practices

  • Use JWT tokens or API keys for authentication.

  • Store state externally (e.g., in Redis, DB, or client-side cookies).

  • Design APIs to be stateless and idempotent for reliability.


Idempotency vs Statelessness

Aspect Idempotency Statelessness
Definition Repeating same request gives same result. Server doesn’t store client context.
Focus Operation safety. Server-side design.
Example DELETE /user/123 multiple times → OK. Each API call includes JWT token.
Goal Prevent duplicate actions. Enable scalability and independence.
Common Use Payment systems, API retries. REST APIs, Microservices, Serverless.