DEV Community: Preeti Sharma

Building Production-Grade Resilience in Microservices with Resilience4j

Preeti Sharma — Sun, 12 Apr 2026 17:07:16 +0000

In the previous article, we explored how the Circuit Breaker Pattern prevents cascading failures in microservices and how to implement it using Resilience4j.

In one real production scenario, a payment service slowdown didn’t fail immediately — it just became slower and slower.

Within minutes, thread pools got exhausted, requests piled up, and multiple services went down — even though the service never “crashed.”

This is where basic circuit breaker setups fall short.

Production systems deal with:

unpredictable traffic spikes
partial failures
slow downstream services
resource exhaustion

To truly build resilient microservices, we need to go beyond the basics.

In this article, we will cover:

Limitations of basic circuit breaker setups
Advanced Resilience4j configurations
Handling slow calls and timeouts
Combining multiple resilience patterns
Observability and monitoring
Real-world best practices

🚨 Why Basic Circuit Breakers Fail in Production

A simple setup like:

@CircuitBreaker(name = "paymentService", fallbackMethod = "fallback")

works in demos — but often fails in production.

Common issues:

The circuit opens too early or too late
Slow services are not treated as failures
No visibility into system health
Threads get blocked due to long waits

👉 Result: Either unnecessary failures or system overload.

⚙️ Advanced Circuit Breaker Configuration

Fine-tuning Failure Detection

resilience4j:
 circuitbreaker:
   instances:
     paymentService:
       slidingWindowSize: 20
       minimumNumberOfCalls: 10
       failureRateThreshold: 50

This prevents the circuit breaker from reacting to small traffic bursts or temporary glitches.

Key idea:

Don’t react to very small sample sizes
Tune based on real traffic patterns

🐢 Handling Slow Calls (Critical in Real Systems)

Not all failures throw exceptions.
In many real systems, latency increases before failures happen — and ignoring this is one of the biggest mistakes engineers make.

slowCallRateThreshold: 60
slowCallDurationThreshold: 2s

This means:

If 60% of calls take more than 2 seconds
Circuit breaker will treat it as a failure

👉 This is crucial for preventing thread pool exhaustion

⏱️ Adding Timeouts with TimeLimiter

Circuit breakers do not stop long-running calls.

We need TimeLimiter:

@TimeLimiter(name = "paymentService")
@CircuitBreaker(name = "paymentService", fallbackMethod = "fallback")
public CompletableFuture<String> processPayment() { 
    return CompletableFuture.supplyAsync(() -> 
        restTemplate.getForObject("/payment", String.class) 
    ); 
}

Now:

Long calls are terminated
System resources are protected

🔄 Combining Resilience Patterns

Real-world systems use multiple patterns together.

1️⃣ Retry + Circuit Breaker

Retry handles temporary failures
Circuit breaker handles persistent failures

resilience4j.retry:
 instances:
  paymentService:
   maxAttempts: 3
   waitDuration: 500ms

2️⃣ Bulkhead Pattern

Prevents one failing service from consuming all resources.

Two types:

Thread pool isolation
Semaphore isolation

👉 Protects your system from overload

3️⃣ Rate Limiter

Controls traffic to downstream services.

Use when:

APIs have rate limits
The downstream service is sensitive to load

📊 Observability: The Game Changer

Without monitoring, circuit breakers are just guesswork.

Enable actuator:
management.endpoints.web.exposure.include: health, metrics

Track:

failure rate
slow call rate
circuit state transitions

Integrate with:

Prometheus
Grafana

👉 This helps you tune configs based on real data

🧠 Designing Effective Fallbacks

Fallbacks should be meaningful.

Bad fallback:
return null;

Good fallback strategies:

return cached data
return default response
show user-friendly message

Example:

public String fallback(Exception e) {
 return "Payment service temporarily unavailable. Please try again.";
}

⚠️ Common Production Mistakes

❌ Same config for all services
❌ Ignoring slow responses
❌ No timeout configuration
❌ Too aggressive retries
❌ No monitoring setup

🏗️ Real-World Flow
Let’s revisit the earlier example:
Client → Order Service → Payment Service

With resilience:

Retry handles temporary issues
The circuit breaker stops repeated failures
TimeLimiter avoids long waits
Bulkhead isolates resources

👉 Result: System stays stable even under failure

🏁 Final Thoughts

Circuit breakers are just one piece of the resilience puzzle.

To build production-grade systems:

Tune configurations carefully
Combine multiple patterns
Monitor everything
Design meaningful fallbacks

The goal is not to eliminate failures.
👉 The goal is to handle failures gracefully without impacting the entire system

Failures are not rare events — they are inevitable.

What separates a stable system from an outage is how well it is designed to handle those failures.

Circuit breakers, timeouts, retries, and bulkheads are not optional optimisations — they are fundamental to building reliable systems.

Building Production-Grade Resilience in Microservices with Resilience4j

Preeti Sharma — Sun, 12 Apr 2026 17:07:16 +0000

In the previous article, we explored how the Circuit Breaker Pattern prevents cascading failures in microservices and how to implement it using Resilience4j.

In one real production scenario, a payment service slowdown didn’t fail immediately — it just became slower and slower.

Within minutes, thread pools got exhausted, requests piled up, and multiple services went down — even though the service never “crashed.”

This is where basic circuit breaker setups fall short.

Production systems deal with:

unpredictable traffic spikes
partial failures
slow downstream services
resource exhaustion

To truly build resilient microservices, we need to go beyond the basics.

In this article, we will cover:

Limitations of basic circuit breaker setups
Advanced Resilience4j configurations
Handling slow calls and timeouts
Combining multiple resilience patterns
Observability and monitoring
Real-world best practices

🚨 Why Basic Circuit Breakers Fail in Production

A simple setup like:

@CircuitBreaker(name = "paymentService", fallbackMethod = "fallback")

works in demos — but often fails in production.

Common issues:

The circuit opens too early or too late
Slow services are not treated as failures
No visibility into system health
Threads get blocked due to long waits

👉 Result: Either unnecessary failures or system overload.

⚙️ Advanced Circuit Breaker Configuration

Fine-tuning Failure Detection

resilience4j:
 circuitbreaker:
   instances:
     paymentService:
       slidingWindowSize: 20
       minimumNumberOfCalls: 10
       failureRateThreshold: 50

This prevents the circuit breaker from reacting to small traffic bursts or temporary glitches.

Key idea:

Don’t react to very small sample sizes
Tune based on real traffic patterns

🐢 Handling Slow Calls (Critical in Real Systems)

Not all failures throw exceptions.
In many real systems, latency increases before failures happen — and ignoring this is one of the biggest mistakes engineers make.

slowCallRateThreshold: 60
slowCallDurationThreshold: 2s

This means:

If 60% of calls take more than 2 seconds
Circuit breaker will treat it as a failure

👉 This is crucial for preventing thread pool exhaustion

⏱️ Adding Timeouts with TimeLimiter

Circuit breakers do not stop long-running calls.

We need TimeLimiter:

@TimeLimiter(name = "paymentService")
@CircuitBreaker(name = "paymentService", fallbackMethod = "fallback")
public CompletableFuture<String> processPayment() { 
    return CompletableFuture.supplyAsync(() -> 
        restTemplate.getForObject("/payment", String.class) 
    ); 
}

Now:

Long calls are terminated
System resources are protected

🔄 Combining Resilience Patterns

Real-world systems use multiple patterns together.

1️⃣ Retry + Circuit Breaker

Retry handles temporary failures
Circuit breaker handles persistent failures

resilience4j.retry:
 instances:
  paymentService:
   maxAttempts: 3
   waitDuration: 500ms

2️⃣ Bulkhead Pattern

Prevents one failing service from consuming all resources.

Two types:

Thread pool isolation
Semaphore isolation

👉 Protects your system from overload

3️⃣ Rate Limiter

Controls traffic to downstream services.

Use when:

APIs have rate limits
The downstream service is sensitive to load

📊 Observability: The Game Changer

Without monitoring, circuit breakers are just guesswork.

Enable actuator:
management.endpoints.web.exposure.include: health, metrics

Track:

failure rate
slow call rate
circuit state transitions

Integrate with:

Prometheus
Grafana

👉 This helps you tune configs based on real data

🧠 Designing Effective Fallbacks

Fallbacks should be meaningful.

Bad fallback:
return null;

Good fallback strategies:

return cached data
return default response
show user-friendly message

Example:

public String fallback(Exception e) {
 return "Payment service temporarily unavailable. Please try again.";
}

⚠️ Common Production Mistakes

❌ Same config for all services
❌ Ignoring slow responses
❌ No timeout configuration
❌ Too aggressive retries
❌ No monitoring setup

🏗️ Real-World Flow
Let’s revisit the earlier example:
Client → Order Service → Payment Service

With resilience:

Retry handles temporary issues
The circuit breaker stops repeated failures
TimeLimiter avoids long waits
Bulkhead isolates resources

👉 Result: System stays stable even under failure

🏁 Final Thoughts

Circuit breakers are just one piece of the resilience puzzle.

To build production-grade systems:

Tune configurations carefully
Combine multiple patterns
Monitor everything
Design meaningful fallbacks

The goal is not to eliminate failures.
👉 The goal is to handle failures gracefully without impacting the entire system

Failures are not rare events — they are inevitable.

What separates a stable system from an outage is how well it is designed to handle those failures.

Circuit breakers, timeouts, retries, and bulkheads are not optional optimisations — they are fundamental to building reliable systems.

How the Circuit Breaker Pattern Prevents Cascading Failures in Microservices

Preeti Sharma — Fri, 06 Mar 2026 11:12:40 +0000

Modern microservice architectures improve scalability and team autonomy, but they also introduce a new challenge: service dependency failures.

If one service becomes slow or unavailable, it can easily cascade across the system, bringing down multiple services.

This is where the Circuit Breaker Pattern becomes extremely important.

In this article we will cover:

The cascading failure problem
How circuit breakers solve it
Circuit breaker states
A working example using Resilience4j
Best practices when using circuit breakers

The Cascading Failure Problem

Imagine a simple microservice system:

Client → Order Service → Payment Service → Database

Now assume the Payment Service becomes slow or unavailable.

What happens?

Order service keeps sending requests.
Requests start waiting.
Threads become blocked.
System resources get exhausted.
Eventually the Order Service also crashes.

This is called a cascading failure.

A single failure spreads across services.

The Circuit Breaker Concept

The concept is inspired by electrical circuit breakers.

When electrical current becomes dangerous, the circuit breaker cuts the flow to prevent damage.

Similarly in microservices, a circuit breaker:

monitors failures
stops sending requests temporarily
allows the system to recover

Instead of continuously calling a failing service, we fail fast.

Circuit Breaker States

A circuit breaker typically has three states.

1️⃣ Closed State

Client → Order Service → Payment Service

Requests flow normally
Failures are monitored
If failures exceed threshold → state changes

2️⃣ Open State

Client → Order Service ✖ Payment Service

Calls are blocked immediately.
No request is sent to failing service.
System return a fallback response.

3️⃣ Half-Open State

Client → Order Service → Payment Service (limited test requests)

Only a few requests allowed.
If they succeed → circuit closes.
If they fail → circuit opens again

Circuit Breaker Flow

Closed → Failures detected → Open
Open → Cooldown period → Half-Open
Half-Open → Success → Closed
Half-Open → Failure → Open

Implementing Circuit Breaker using Resilience4j

One of the most popular circuit breaker libraries in Java is Resilience4j.
It works very well with Spring Boot.

Add Dependency

<dependency>
 <groupId>io.github.resilience4j</groupId>
 <artifactId>resilience4j-spring-boot3</artifactId>
</dependency>

Configure Circuit Breaker

application.yml

resilience4j:
  circuitbreaker:
    instances:
      paymentService:
        registerHealthIndicator: true
        slidingWindowSize: 10
        minimumNumberOfCalls: 5
        failureRateThreshold: 50
        waitDurationInOpenState: 10s

Explanation:

slidingWindowSize → number of calls monitored
failureRateThreshold → percentage to trigger breaker
waitDurationInOpenState → time before retry

Applying Circuit Breaker to a Service

Example: calling a Payment Service.

@Service
public class PaymentClient {

    @CircuitBreaker(name = "paymentService", fallbackMethod = "fallbackPayment")
    public String processPayment() {

        // call external payment service
        return restTemplate.getForObject(
            "http://payment-service/pay",
            String.class
        );
    }

    public String fallbackPayment(Throwable ex) {
        return "Payment service unavailable. Please try later.";
    }
}

What happens here:

Calls go normally.
If failure rate exceeds threshold → circuit opens.
All calls go directly to fallback method.

What a Fallback Response Looks Like

Fallback responses prevent system crashes.

{
 "status": "FAILED",
 "message": "Payment service temporarily unavailable"
}

Instead of crashing, the system degrades gracefully.

When Should You Use Circuit Breakers?

Circuit breakers are useful when:

calling external APIs.
calling slow microservices.
interacting with unreliable networks.

Typical examples:

Order Service → Payment Service
Checkout Service → Inventory Service
API Gateway → User Service

When NOT to Use Circuit Breakers

Avoid using circuit breakers for:

database calls inside the same service
very fast local operations
in-memory calls

Circuit breakers are best suited for remote network calls.

Best Practices

✔ Always define fallback responses
✔ Monitor breaker metrics
✔ Combine with retry mechanism
✔ Use timeouts with circuit breakers

Final Thoughts

Microservices improve scalability and flexibility, but they also introduce reliability challenges when services depend on each other. A failure in one service can quickly propagate and lead to cascading failures across the system.

The Circuit Breaker Pattern helps prevent this by stopping repeated calls to failing services and allowing systems to fail fast with fallback responses. Tools like Resilience4j make it easy to implement this pattern in Spring Boot applications.

In the next article, we’ll explore building production-grade resilience using Resilience4j, including retries, bulkheads, and other advanced patterns.

Stay tuned for the next part of this series 🚀

Backpressure: Why “Just Handle More Traffic” Is the Wrong Mindset

Preeti Sharma — Fri, 20 Feb 2026 10:11:30 +0000

When we talk about scaling systems, the default thought is:

“How do we handle more requests?”

But the better question is:

“What happens when we receive more than we can handle?”

That’s where backpressure becomes important.

Not as a buzzword.

As a stability mechanism.

The Real Problem

In any backend system, different components have different capacities.

API receives 10k requests/sec
Service layer handles 6k/sec
Database handles 3k/sec

That gap doesn’t disappear — it accumulates.

It turns into:

Growing queues
Thread pool exhaustion
Memory pressure
High GC
Increased latency

Eventually → failure.

Backpressure exists to prevent that.

So What Is Backpressure?

At its core:

Backpressure is a flow-control mechanism in which the consumer controls how much data it receives from the producer.

Instead of:
Producer → pushes endlessly
Consumer → keeps accepting

We get:
Consumer → “Give me 100. I’ll ask again when ready.”

That simple shift changes system behaviour completely.

This Is Not Just a Reactive Concept

Yes, it’s formally defined in the Reactive Streams specification

and implemented in frameworks like:

Project Reactor
RxJava
Spring WebFlux

But the idea applies even in regular Spring Boot applications.

Think about:

Tomcat thread pool → limited
DB connection pool → limited
CPU cores → limited

If incoming rate > processing rate, the excess work sits in memory.

That’s uncontrolled buffering.

Backpressure is about making that buffering intentional and bounded.

Push vs Pull (Practical View)

Without Backpressure

while(true) {
   sendEvent();
}

Consumer side:

Queue keeps growing…
Memory increases…
Latency increases…

Nothing crashes immediately.

But performance degrades silently.

With Backpressure

subscription.request(50);

Producer:

Send exactly 50.
Wait for next request.

The system becomes predictable.

And predictability is what makes systems reliable.

The Important Insight

Backpressure is not about slowing down traffic.

It’s about aligning work with capacity.

If a service can process 2,000 requests per second,
it should not accept 10,000 and “hope for the best.”

That hope becomes technical debt.

Where This Matters in Real Systems

1. Kafka Consumers

If consumer speed < producer speed:

Lag increases
Memory grows
Rebalances become frequent

Smart systems:

Control poll size
Pause consumption
Scale consumers

That’s practical backpressure thinking.

2. Database Writes

If DB supports 2k writes/sec
but API accepts 8k writes/sec:

You don’t have a scaling problem.

You have a flow-control problem.

3. Reactive APIs

In Spring WebFlux, you can do:

Flux.range(1, 1_000_000)
    .limitRate(100)
    .subscribe();

It processes data in chunks instead of flooding the subscriber.

That’s backpressure applied.

Most systems don’t fail instantly.
They degrade first.

Final Thought

Scaling isn’t just about handling more.

It’s about knowing when to slow down.

Backpressure is simply this principle:

Never accept more work than you can process safely.

And once you start thinking that way, you design systems differently.

More stable.
More predictable.
And far less fragile under pressure.

Sequential vs Parallel API Calls in Spring Boot

Preeti Sharma — Fri, 13 Feb 2026 11:22:35 +0000

In microservice architecture, it’s common for one service to call multiple downstream services.

But what many developers miss is how those calls are executed — sequentially or in parallel.

Let’s understand this with a simple example.

🧩 Problem Statement

Suppose Service A needs data from:

Service B → takes 1 second
Service C → takes 1 second

If Service A calls them one after another, what will be the total response time?

👉 2 seconds.

Why? Because it waits for B to finish before calling C.

Let’s implement this in Spring Boot.

🔴 Part 1 — Sequential Execution

Fake downstream endpoints

@RestController
@RequestMapping("/api")
public class TestController {

    @GetMapping("/service-b")
    public ResponseEntity<String> serviceB() throws InterruptedException {
        Thread.sleep(1000);
        return ResponseEntity.ok("Response from service B");
    }

    @GetMapping("/service-c")
    public ResponseEntity<String> serviceC() throws InterruptedException {
        Thread.sleep(1000);
        return ResponseEntity.ok("Response from service C");
    }
}

Sequential call

 @GetMapping("/sequential")
    public ResponseEntity<String> sequential() {
        long start = System.currentTimeMillis();

        String baseUrl = "http://localhost:8080/api";
        String serviceBResponse = restTemplate.getForObject(baseUrl + "/service-b", String.class);
        String serviceCResponse = restTemplate.getForObject(baseUrl + "/service-c", String.class);

        long end = System.currentTimeMillis();
        String response = "Result: " + serviceBResponse + " & " + serviceCResponse + " | Time Taken: " + (end - start) + " ms";

        return ResponseEntity.ok(response);
    }

⏱ Output

Result: Response from service B & Response from service C | Time Taken: 2065 ms

🟢 Part 2 — Making It Asynchronous

Instead of waiting for one call to finish, we can trigger both calls at the same time using CompletableFuture.

Parallel Implementation

@GetMapping("/parallel")
    public ResponseEntity<String> parallel() throws ExecutionException, InterruptedException {
        long start = System.currentTimeMillis();
        String baseUrl = "http://localhost:8080/api";

        CompletableFuture<String> responseB = CompletableFuture.supplyAsync(
                () -> restTemplate.getForObject(baseUrl + "/service-b", String.class)
        );

        CompletableFuture<String> responseC = CompletableFuture.supplyAsync(
                () -> restTemplate.getForObject(baseUrl + "/service-c", String.class)
        );

        CompletableFuture.allOf(responseB, responseC).join();

        long end = System.currentTimeMillis();

        String response = "Result: "+ responseB.get() + " & " + responseC.get() + " | Time taken: "+ (end-start) + " ms";
        return ResponseEntity.ok(response);
    }

⏱ Output

Result: Response from service B & Response from service C | Time taken: 1061 ms

Now total time equals the slowest service, not the sum of both.

Mathematically:
Total Time = max(Service B, Service C)

🎯 Why This Matters

Sequential execution:

Increases API latency
Blocks threads longer
Reduces throughput under load

Parallel execution:

Reduces response time
Improves user experience
Utilises threads efficiently

🧠 Key Takeaways

Sequential calls add up execution time.
Parallel execution reduces total latency.
Asynchronous programming is essential in microservice communication.
Using CompletableFuture helps coordinate multiple async tasks cleanly.

Sequential vs Parallel API Calls in Spring Boot

Preeti Sharma — Fri, 13 Feb 2026 11:22:34 +0000

In microservice architecture, it’s common for one service to call multiple downstream services.

But what many developers miss is how those calls are executed — sequentially or in parallel.

Let’s understand this with a simple example.

🧩 Problem Statement

Suppose Service A needs data from:

Service B → takes 1 second
Service C → takes 1 second

If Service A calls them one after another, what will be the total response time?

👉 2 seconds.

Why? Because it waits for B to finish before calling C.

Let’s implement this in Spring Boot.

🔴 Part 1 — Sequential Execution

Fake downstream endpoints

@RestController
@RequestMapping("/api")
public class TestController {

    @GetMapping("/service-b")
    public ResponseEntity<String> serviceB() throws InterruptedException {
        Thread.sleep(1000);
        return ResponseEntity.ok("Response from service B");
    }

    @GetMapping("/service-c")
    public ResponseEntity<String> serviceC() throws InterruptedException {
        Thread.sleep(1000);
        return ResponseEntity.ok("Response from service C");
    }
}

Sequential call

 @GetMapping("/sequential")
    public ResponseEntity<String> sequential() {
        long start = System.currentTimeMillis();

        String baseUrl = "http://localhost:8080/api";
        String serviceBResponse = restTemplate.getForObject(baseUrl + "/service-b", String.class);
        String serviceCResponse = restTemplate.getForObject(baseUrl + "/service-c", String.class);

        long end = System.currentTimeMillis();
        String response = "Result: " + serviceBResponse + " & " + serviceCResponse + " | Time Taken: " + (end - start) + " ms";

        return ResponseEntity.ok(response);
    }

⏱ Output

Result: Response from service B & Response from service C | Time Taken: 2065 ms

🟢 Part 2 — Making It Asynchronous

Instead of waiting for one call to finish, we can trigger both calls at the same time using CompletableFuture.

Parallel Implementation

@GetMapping("/parallel")
    public ResponseEntity<String> parallel() throws ExecutionException, InterruptedException {
        long start = System.currentTimeMillis();
        String baseUrl = "http://localhost:8080/api";

        CompletableFuture<String> responseB = CompletableFuture.supplyAsync(
                () -> restTemplate.getForObject(baseUrl + "/service-b", String.class)
        );

        CompletableFuture<String> responseC = CompletableFuture.supplyAsync(
                () -> restTemplate.getForObject(baseUrl + "/service-c", String.class)
        );

        CompletableFuture.allOf(responseB, responseC).join();

        long end = System.currentTimeMillis();

        String response = "Result: "+ responseB.get() + " & " + responseC.get() + " | Time taken: "+ (end-start) + " ms";
        return ResponseEntity.ok(response);
    }

⏱ Output

Result: Response from service B & Response from service C | Time taken: 1061 ms

Now total time equals the slowest service, not the sum of both.

Mathematically:
Total Time = max(Service B, Service C)

🎯 Why This Matters

Sequential execution:

Increases API latency
Blocks threads longer
Reduces throughput under load

Parallel execution:

Reduces response time
Improves user experience
Utilises threads efficiently

🧠 Key Takeaways

Sequential calls add up execution time.
Parallel execution reduces total latency.
Asynchronous programming is essential in microservice communication.
Using CompletableFuture helps coordinate multiple async tasks cleanly.

Why APIs Are Contracts, Not Just Endpoints

Preeti Sharma — Mon, 09 Feb 2026 10:26:37 +0000

Treating APIs as “just endpoints” is a costly mistake

Early in my career, I thought of APIs mainly as endpoints — URLs that return data so the frontend can move forward.

Over time (and after a few production incidents), I learned this mental model doesn’t scale.

APIs are not just endpoints.
They are contracts.

APIs live longer than features

Frontend code changes fast.
Backend APIs tend to outlive multiple UI versions, clients, and even teams.

When an API changes:

Mobile apps might not update immediately
Older clients may still depend on previous behaviour
Silent breakages can take weeks to surface

Once an API is public (even internally), it’s no longer “just code”.

Small changes can have big consequences

Some examples that seem harmless but aren’t:

Changing a response field name
Removing a field that “no one uses”
Returning a different HTTP status code
Reusing error messages for multiple failure cases

Each of these can:

Break clients
Cause unexpected UI behaviour
Create hard-to-debug production issues

The backend may still be “correct”, but the system isn’t.

What changed in how I design APIs now

A few shifts that helped:

Think in contracts, not implementations
What matters is what the client expects, not how the backend is built.
Be explicit about errors
Clear error codes and messages are more valuable than generic failures.
Prefer additive changes
Adding fields is safer than modifying or removing existing ones.
Assume clients won’t update immediately
Backward compatibility is part of API design, not a nice-to-have.

Why this matters even more in product & fintech systems

In product-driven and fintech systems:

APIs often power money movement, identity, or critical workflows
Correctness matters more than speed of change
Breaking behaviour can directly impact users and trust

Here, API discipline is not over-engineering — it’s a responsibility.

Treating APIs as contracts changed how I design, review, and evolve backend systems.
It made my work slower at the start — and far safer in the long run.