Task 1 (Data Structure) Task 2 (Terminology standardization) Task 3 (impact of change) Mission 1 (Decision Making) Mission 2 (Exception Scenario) 📊 View Summary ← Classroom
Day 4 Mission 01 Decision logging

Mission 01. Review and improve design API (Design Decision Log)

Automatically creates a standard Design Decision Log (Why) report that records database normalization methods and architecture decisions.

Mission 1 Design API review and improvement practice guide

📥 Practice Input

  • • day4_api_review_dialogue.md (meeting conversation transcript)

💾 Practice output (Output)

  • • design-decision-log.md (API Review and Improvement Document)

1. Story and practice background

This is pointed out by an external architecture advisor who saw the API documentation of the startup that first built it. "The URL structure is made up of verbs like `/api/v1/getUsers`, and when an error occurs, an error message is sent in the response body with HTTP Status set to 200 Ok. And when modifying resources, PUT and PATCH are used together. This structure does not comply with scalability and general developer tool standards, resulting in enormous refactoring costs during future advancement."

Failure to adhere to standard API design philosophy and style rules (REST API standards, naming conventions, and consistent exception specifications) in the early design stages will cause development barriers during external integration (Payment PG, external partnerships).

In this mission, the background of data normalization and architecture decision made in the technical design stage was standardized using Codex. Design Decision Log Learn how to safely manage a system's historical assets and design rationale (why) by documenting them.

2. Learning objectives

  • Normalization and database structure design decisions can be accurately extracted from meeting minutes.
  • Decision items, background reasons, review of alternatives, approvers, and possibility of future changes can be specified.
  • By recording the history (why) of design decisions, you can prevent duplicate meetings and mistakes by new team members.

🛠️Practical guide to follow along

  1. Create file for practice: Click the download button below to download the API specification draft and review meeting transcript files. automation/ Save it within the folder.
  2. Codex logging delegation: Build by sending the **Codex request prompt** below to the Codex Client prompt input window.
  3. log check: In the printed report, review whether the decision ID (DEC-003), decision background, review alternative (reason for rejection), and approval entity are structured correctly.

Download practice materials (2 Files)

Codex request prompt

Mission 01 Prompt
Please review the provided API specification of day4_api_specification_v1.md, analyze improvements based on REST API design standards (HTTP Method usage, URL naming), consistent error handling structure, and extensibility, and write an API review report.

4. Example results

Codex documents the architectural conclusions and the basis for compromise in the conversation history as follows.

[Decision ID: DEC-003]
• decision: Reservation cancellation history is designed to be separated 1:N into a separate Reservation_Histories table instead of accumulating it directly in the Reservations table.
• AS-IS (Current Design): Prevents write lock bottlenecks on the main table due to frequent reservation status changes and meets history tracking requirements by date and agent.
• review alternatives: Directly add canceled_at, cancel_reason to the Reservations table (dismissal: cannot record multiple cancellation history and risk of table bloat)
• approval entity: PM and Lead Engineer (Approver: Dev_Lead)
• Possible changes in the future: When large-scale traffic occurs, history may be transferred to NoSQL Document DB.