[Class Report] Systems Development (Year 3) — Week 45

~Multi-API Integration and Asynchronous Design: Controlling “Wait Time” and “Failure” Through Design~

In Week 45, we built on the API integrations introduced in previous lessons and learned how to design systems that handle multiple APIs at once, as well as how to implement approaches that assume asynchronous behavior (waiting time and partial failures).
The theme was achieving all three at once: speed, stability, and clarity.

■ Teacher’s Introduction: “The More APIs You Add, the More ‘Waiting’ and ‘Failures’ You Get”

Mr. Tanaka: “When you combine two or three APIs, it becomes normal for
‘one of them is slow’ or ‘one of them fails.’
Today, let’s learn how to absorb that through design.”

The teacher showed how calling APIs sequentially with synchronous processing slows everything down, and explained why asynchronous and parallel thinking becomes necessary.

■ Today’s Goals

1. Be able to design a use case that integrates multiple APIs
2. Understand the difference between synchronous and asynchronous processing
3. Grasp how parallel execution reduces waiting time
4. Implement a design that does not stop the whole system even if some APIs fail

■ Exercise ①: Designing a Multi-API Use Case

We started by clarifying which APIs to combine.

Examples discussed in class

• Library system
  • Weather API: display a “return reminder” notice
  • Holiday API: decide whether to extend the due date
• Learning support app
  • Translation API: help with English
  • Dictionary API: show word meanings

Student A: “If one API is ‘support’ and the other is ‘decision input,’ it’s easier to organize.”

■ Exercise ②: Experiencing the Problems with Synchronous Processing

First, we tested code that calls APIs synchronously (in order).

weather = weather_api.fetch(city)
holiday = holiday_api.fetch(date)

Problems we experienced:

• The total time becomes long
• If either one fails, the entire process stops
• Users clearly feel like they are being “kept waiting”

Student B: “Even if only one API is slow, everything feels slow…”

■ Exercise ③: Learning the Idea of Asynchronous + Parallel Execution

Next, we introduced the concept of calling APIs at the same time.
(In class, we focused on concepts and used a simplified async example.)

Concept image

weather_task = async_fetch_weather(city)
holiday_task = async_fetch_holiday(date)

weather, holiday = await gather(weather_task, holiday_task)

Key points:

• By waiting simultaneously, the total wait time becomes roughly “the slowest API’s time”
• The perceived speed improves significantly

Student C: “It feels like things are running in parallel in the background—suddenly it’s very ‘real-world.’”

■ Exercise ④: Designing to Tolerate Partial Failure

With multiple APIs, it’s important not to assume “everything succeeds.”

Design policy

• Lower-priority APIs should not block the whole flow if they fail
• Treat results as a Result (success/failure)
• Make the final decision in the Service layer

weather = safe_fetch_weather(city)   # returns None on failure
holiday = safe_fetch_holiday(date)

message = build_message(weather, holiday)

UI examples:

• “Today is a holiday. The return deadline will be extended.”
• “Weather information could not be retrieved.”

Student D: “It’s reassuring to design it so it doesn’t require everything to be available.”

■ Exercise ⑤: Designing Priority and Display Timing

Finally, we discussed what to show first.

• Show the main function immediately
• Show/update supplementary API info later
• Use loading indicators so waiting is visible

Student E: “If you’re going to make users wait, it’s better if they can tell that they’re waiting.”

The teacher added a practical note:
“UX isn’t only about being ‘fast’—it’s also about being ‘convincing and understandable.’”

■ Class-Wide Insights

• The more APIs you integrate, the more design quality matters
• Async is not only a way to “make it faster,” but also to “make it more resilient”
• The Service layer becomes even more important
• In some cases, it’s kinder UX to not wait for everything to be ready

■ The Teacher’s Closing Message

“Multi-API integration brings both
‘convenience’ and ‘instability’ into your system.

That’s why it’s essential to build
parallelism, partial failure handling, and prioritization into the design.
Today’s ideas apply directly to generative AI and large-scale service integration, too.”

■ Homework (for next week)

1. Create a simple use case design diagram (basic sequence diagram) using multiple APIs
2. Classify APIs into “critical” vs. “supporting,” and explain why
3. Propose one UI display plan for when half of the APIs fail

■ Next Week Preview: Intro to Designing Generative AI Integration

Next week, we’ll finally move into
designing how to integrate generative AI into systems.
The focus won’t be “how to call it,” but
“how to control it and use it safely.”

Week 45 was an important milestone in learning how to design API integrations that don’t break when they scale up.
Students are beginning to develop a higher level of system design skill—thinking about speed, stability, and UX at the same time.