DEV Community: Tohru Yaginuma

Web APIs and Batch Jobs Communicate Failure Differently

Tohru Yaginuma — Sat, 22 Aug 2026 23:58:22 +0000

Long Story Short

Web APIs can communicate failure through HTTP status codes, but batch jobs need to terminate in a way that allows the execution environment to recognize that the process has failed.
In this case, I changed the error handling to throw an exception. This caused failed Lambda invocations to be reflected in the CloudWatch Errors metric, which allowed the alarm to trigger.
Error handling does not end inside the application. We also need to think about whether failures can be correctly observed by the monitoring and alerting systems outside it.

Context

Recently, I had the opportunity to implement a mechanism that sends a Slack notification when a batch job running on AWS fails.

The batch job itself was an existing Lambda function that was already running in production, so I initially thought the task would be relatively simple.

The setup was to monitor Lambda execution errors with CloudWatch and send notifications to Slack through AWS notification services.

The AWS-side configuration itself was not particularly complicated.

However, when I looked at the existing batch code that we wanted to monitor, I found a problem.

An Error Was Happening, but the Job Wasn't Failing

The existing error handling included code like this:

return false

or:

return { status: 500 }

The intention was probably to indicate that an error had occurred.

From Lambda's perspective, however, that is not what happens.

Returning false or { status: 500 } simply means that the Lambda function returned a value and completed successfully.

Just because the returned value contains the number 500 does not mean that Lambda automatically treats the invocation as a failure.

As a result, even though the application code intended to handle the situation as an error, the execution environment still saw it as a successful invocation.

Because of that, the invocation was not treated as a function error and was not reflected in CloudWatch's Errors metric.

The CloudWatch Alarm therefore did not trigger, and no Slack notification was sent.

Building the monitoring mechanism made me realize that the existing error handling was not communicating the failure correctly to the systems outside the application.

I Couldn't Apply the Same Mental Model as a Web API

What I found interesting was the difference between how Web APIs and batch jobs communicate failure.

In a Web API, we use HTTP status codes to communicate the result of a request to the client.

For example:

HTTP 500 Internal Server Error

By returning an HTTP 500 response, the client can recognize that the request has failed.

When you spend a lot of time working with Web APIs, it becomes natural to think:

If something goes wrong, return 500.

But what I was working with this time was not a Web API responding to an HTTP request. It was a batch job running on Lambda.

There was no client waiting for an HTTP response.

What mattered was not returning a value that contained 500, but making the Lambda invocation itself fail.

In this case, I refactored the code to throw an exception when an error occurred:

throw new Error(...)

This caused the Lambda invocation itself to fail, which was then reflected in the CloudWatch Errors metric.

Error Handling Doesn't End Inside the Application

When I started this task, I thought I was simply adding a Slack notification for batch failures.

But once I followed the notification flow back to the existing code, I ended up asking a more fundamental question:

Is this application actually communicating its failures correctly to the outside world?

Writing an error log.

Returning false.

Returning a value containing 500.

If you only look at the application code, all of these can appear to be forms of error handling.

But if the Lambda runtime and CloudWatch cannot observe the execution as a failure, that error handling does not connect to monitoring or alerting.

This experience made me realize that when thinking about error handling, I should consider not only:

"How is the error handled inside the code?"

but also:

"Who needs to observe this failure, and how will they know that it happened?"

Conclusion

Web APIs communicate success and failure to clients through HTTP status codes.

Batch jobs are different. We need to think about how the execution environment determines whether a job succeeded or failed.

Implementing this Slack notification mechanism made me realize that the familiar Web API mindset of "return 500 when something fails" cannot simply be applied to batch jobs.

Error handling is not only an application-level concern.

I learned that part of error handling is also making sure that a failure can be correctly observed by the execution environment and the monitoring systems around the application.

Designing HTML Page Caching Changed How I Think About Caching

Tohru Yaginuma — Sun, 16 Aug 2026 15:09:34 +0000

Long Story Short

Designing HTML page caching in practice connected several concepts I had previously understood separately, such as TTL, browser caching, and where cache policies should live.
In our architecture, where HTML pages are cached with CloudFront, the choice between CSR and SSR also affects whether data can benefit from the HTML cache.
Starting from the simple goal of “caching pages” made me think more broadly about what should be cached and where, including API responses and backend caching.

Context

Recently, I had the opportunity to design HTML page caching for a web platform at work.

It was my first time designing HTML page caching in practice, and we used AWS CloudFront as our CDN.

I already had a basic understanding of caching.

Store a response once, reuse it later, reduce server-side processing, and improve response times.

At least conceptually, I thought I understood it.

The task also seemed relatively simple at first.

If we cache HTML pages in CloudFront, requests don’t need to reach the application every time.

Then we just need to decide which pages to cache and how long their TTLs should be.

Once I actually started working on the design, however, I realized there was more to think about.

Looking at CSR and SSR Through the Lens of Caching

One of the things I found particularly interesting was the relationship between CSR, SSR, and HTML page caching.

I had previously thought about CSR and SSR mainly in terms of where rendering happens.

With CSR, rendering happens in the browser. With SSR, HTML is generated on the server.

From there, I would usually think about things like SEO and initial page-load performance.

None of that was new to me.

But designing HTML page caching gave me another perspective on CSR and SSR.

In our case, CloudFront caches HTML pages.

This means that when data is fetched during SSR and included in the HTML, the resulting HTML — including that data — can be served from the CloudFront cache.

With CSR, on the other hand, the browser fetches data from an API after receiving the HTML. That data is therefore outside the HTML page cache.

Of course, this doesn’t mean that “SSR is cacheable” and “CSR is not.”

SSR-generated HTML doesn’t have to be cached, and API responses fetched through CSR can be cached at other layers.

But in our architecture, the choice between CSR and SSR affects whether that data can benefit from the HTML page cache.

I had previously viewed CSR and SSR primarily as rendering strategies, so seeing this connection in practice was interesting to me.

Caching Exists Beyond HTML

Thinking about CSR led me to another question:

What about the API responses fetched by the client?

For this project, the scope was HTML page caching with CloudFront. I hadn't really considered API response caching as part of the same problem at that point.

But while thinking about CSR and SSR, I realized that API responses can also be cached at different layers, such as a CDN or the backend itself.

That made me realize that I had been thinking about caching too narrowly, mostly in terms of HTML pages.

Do we cache the HTML?

Do we cache API responses?

Do we cache something in the browser?

At the CDN?

On the backend?

They are all forms of caching, but each comes with different considerations.

I didn’t design API caching as part of this project.

Still, thinking about HTML page caching made me look beyond HTML and think more deeply about caching across the system. That itself was an important learning for me.

TTL Needs a Reason Too

TTL was another area I hadn’t thought deeply about until I had to design it myself.

A longer TTL allows a cached response to be reused for longer.

But it also means that stale content can remain visible for longer after the underlying page has been updated.

Not every page has the same traffic or update frequency either.

Some pages receive a lot of traffic but rarely change. Others may change relatively frequently.

Once I started thinking about actual pages, I realized that TTL wasn’t simply a matter of choosing a “long” or “short” value.

It was a trade-off involving how fresh each page needed to be.

I used to think of TTL mostly as a configuration value. This experience made me realize that the value itself should have a reason behind it.

Where Should Caching Decisions Live?

Another question was where the decision about which pages to cache should live.

We could define rules in CloudFront based on URLs and other conditions.

But the application often has the most context about whether a particular page is safe to cache.

In our design, we decided to keep information about cacheable pages on the application side and use that information to control caching behavior in CloudFront.

Before this project, I partly thought of HTML page caching as CDN configuration.

Working on the design made me realize that it can also be an application design question:

Where should the responsibility for caching decisions live?

A Clearer Mental Model of Caching

I don’t feel that I learned one particular new caching technology from this experience.

The bigger learning was that concepts I had previously understood separately started to connect.

CSR and SSR.

CDNs.

TTL.

Browser caching.

API response caching.

Backend caching.

I already knew these terms and concepts individually.

But designing HTML page caching myself forced me to think about them in terms of a real system: What should we do here?

The questions I ask about caching have also changed.

What are we caching?

Where are we caching it?

Who can safely share the cached response?

How fresh does it need to be?

There is still plenty I don’t know.

But I now have a much clearer idea of what questions I should be asking.

Designing HTML page caching gave me a much clearer mental model of caching than I had before.

Async-First Doesn’t Mean Async-Only

Tohru Yaginuma — Sun, 09 Aug 2026 20:27:34 +0000

Key Takeaways

Asynchronous discussions can lose momentum because participants are focused on different tasks. For complex or important topics, it’s often better to switch to synchronous communication.
At least in my experience working in a Japanese-speaking organization, AI-generated messages are often still too verbose to send as-is. As writing becomes cheaper, it’s even more important to reduce the cognitive load on readers.
Async-first does not mean async-only. Keeping written records while introducing short meetings when necessary can reduce the overall cost of communication.

Context

I currently work from Vancouver, Canada, for a fully remote and fully flexible organization based in Japan.

Since everyone works on their own schedule, much of our day-to-day communication, decision-making, and discussion happens asynchronously.

There are many benefits to this way of working. People can think at their own pace, and discussions naturally leave a written record.

As someone who is fairly introverted, I also appreciate having time to think through my ideas before sharing them.

Recently, however, I’ve started to realize that keeping every discussion asynchronous is not always the most efficient approach.

Complex discussions are expensive to read

When discussing multiple options, I usually start by sharing my recommendation, then document the reasoning behind it and the pros and cons of alternative approaches.

The more complicated the topic becomes, the longer the document becomes.

Writing requires effort, but so does reading. Someone has to understand the background, process the trade-offs, form an opinion, and respond.

Lately, I’ve become more aware of the reader’s cost than the writer’s.

In our company, Japanese is the shared language, and much of our written communication is now assisted by AI. While AI makes it easier to produce long documents, the resulting text can still be unnecessarily verbose or difficult to follow.

AI makes writing cheaper. It does not necessarily make reading cheaper.

On top of that, everyone already has their own priorities.

When a message arrives, people are often in the middle of something else. Replies become spread out over hours or days. Discussions can lose momentum, and important but non-urgent topics may eventually fade away without reaching a conclusion.

Write first, then talk

To address this, I’ve started scheduling short meetings whenever a discussion becomes too complex to resolve asynchronously.

This doesn’t mean abandoning written communication.

I still document the background, context, and available options. AI helps me draft these documents quickly, but I always review and simplify them before sharing.

Once everyone has the necessary context, a short meeting allows the team to focus on the same problem at the same time.

I’ve found that questions that would otherwise require many rounds of messages can often be resolved in just a few minutes of conversation.

There’s another benefit as well.

In a fully remote, fully flexible environment, opportunities to talk to teammates naturally become less frequent. Even when the purpose is purely technical, real-time conversations can help build mutual understanding and trust.

Async-first doesn’t mean avoiding meetings

I used to believe that if a team was designed around asynchronous communication, then most discussions should stay asynchronous.

I don’t think that anymore.

Asynchronous communication is a tool, not the goal.

If a topic is simple, asynchronous communication works well. If a discussion becomes complex, stalls, or requires multiple rounds of clarification, a short synchronous conversation can be the more efficient option.

I’ve learned not to hesitate to schedule a meeting when it helps move an important discussion forward.

Being async-first doesn’t mean avoiding synchronous communication.

It means choosing the communication style that minimizes the overall cost for the team.