ASSIGNMENT 8 · CHAPTER 17
Reason about a lost remote response
Read the named source pages, check the five objectives, apply the concepts, then reassess your decision when new evidence appears. The total-time estimate includes preparation; report your actual time.
Practical hour. This build is this chapter’s practical hour. The assignment is not submitted without it. Running the tests is a separate row in the rubric; longer writing does not make up for it.
الساعة التطبيقية. هذا البناء هو الساعة التطبيقية لهذا الفصل. لا يُسلَّم الواجب بدونه. تشغيل الاختبارات صف مستقل في السلّم، لا يُعوَّض بطول الكتابة.
Course learning outcome 9: Explain distributed systems and architectures, practised by building and testing the idempotent service. The tests and the coverage step practise outcome 11: design and implement test cases across testing strategies.
مخرج التعلم 9: شرح الأنظمة الموزعة ومعمارياتها، ويُمارَس ببناء الخدمة التي لا تكرر الحجز واختباره. والاختبارات وخطوة التغطية تمارس المخرج 11: تصميم حالات الاختبار وتنفيذها.
- Warm-up
- FIT → FAILURE → BOUND → ACT + EVIDENCE
- Commit Part A
- STRESS → REFIT
- AI declaration + human review
- Export and submit in LMS
1 · WARM-UP · 5 MINUTES · NOT GRADED
You send a payment request to another computer, but the waiting time ends with no reply. Can you assume no payment happened?
Show / hide warm-up answer
No. The server may have completed the payment before its reply was lost. Before sending the request again, define how to identify the same request, prevent a second effect, or check the saved result.
Lecture guide
X02A, X03, X05, R09 and X09; original slides 14–28 and 53–64. Retry-specific reasoning is a labelled course application.
FIT identifies the relevant problem. FAILURE builds this chapter’s artifact. BOUND states the limits. ACT + EVIDENCE records the action, owner and verification. STRESS then tests your reasoning before REFIT.
Chapter map · Relevant mechanism · 20-rule map · Practice card. Source and chapter-unit identifiers are not canonical rule numbers.
CURRENT EDITION · MASTERY V2
Required preparation and assessment scope
Read: Distributed architectural patterns: slides 29–34; SaaS and service delivery: slides 53–58.
Complete the five-objective preparation check after the assigned reading before you start.
Scope notes and earlier editions
Blackboard supplies the calendar deadline. All five chapter objectives, the classroom concepts and named reading are in assessment scope. Optional toolkit activities are enrichment unless assigned.
One assigned source application and one short transfer answer are included below, within the existing 5-point rubric. A reading click or a practice score is not proof of mastery.
Already started the previous edition? Resume or export your previous work using the same ID and browser. Previous drafts stay separate. Completed submissions do not need repeating unless the instructor requests it.
READ BEFORE ANSWERING
How your work is assessed · 5 points
| Criterion | Scoring |
|---|---|
| FIT · 1 point | 1: Defines the problem using the chapter ideas accurately, distinguishes facts from assumptions and connects it to the proposed action. The short answer applying a second chapter idea must correctly apply the second concept; FIT and that answer together earn this single point.Partial credit: 0.75 · 0.5 · 00.75: The right concept and mechanism, but one link is thin: a fact and an assumption are not separated, or the transfer answer applies the second concept only partly.0.5: A relevant concept is named but applied generically or to the wrong mechanism, or the transfer answer is missing or incorrect. 0: No chapter concept is applied, the case is misread, or the answer depends on invented facts. A generic “hold and test” statement does not satisfy this criterion. |
| FAILURE · 1 point | 1: A causally correct failure sequence, justified retry or reconciliation rule, and a test that distinguishes one committed action from duplicate actions. Apply one idea from the assigned reading to your technical work and explain the connection. Include your predicted outcomes, both local runs and a correct interpretation of any discrepancy; test logs replace a descriptive paragraph. Build: every course check passes, your own tests catch every known bug (mutation test), and you can make your code change for the short discussion (micro-viva) and explain which tests change; the text uses what the build showed.Partial credit: 0.75 · 0.5 · 00.75: A correct failure sequence and rule, but the test misses one case—for example, a restart or a genuinely different request identifier.0.5: The sequence confuses a lost response with a failed operation, or the retry rule would still allow duplicate effects. Or the build fails course checks that the written record does not explain. 0: No causal failure sequence or test log, or results reported without running the local models. |
| TESTS RUN · required | Required for submission: a recorded run of your own tests and the course checks on your final code, a second run after you change one test input, and the coverage sentence. Part A cannot be committed without them. Not replaceable: longer writing does not make up for a missing run. A run with failing checks is accepted when your text explains it. The build itself is marked in FAILURE. |
| THEIR CHANGE · required | Required for submission: run 3, their change, with your code and tests unchanged, and your answer to two questions: did your tests stay green, and is the result still correct? Not met when your answer does not match what the run shows, for example “the result is still correct” when it is not. This row adds no points and takes none; the instructor reviews a row that is not met. |
| IN-CLASS CHECK · required | Two questions on paper in the lecture after the deadline, with no devices, about your own submission: a small change to your code and one new fact. Both correct: the mark stands. One correct: the mark is halved. Neither: a two-minute conversation with the instructor decides. This row adds no points. See AI rules and the in-class check. |
| BOUND · 1 point | 1: States relevant assumptions, the situations covered, and a result you can observe that would make you review the decision. Partial credit: 0.75 · 0.5 · 00.75: A relevant boundary and trigger, but one is imprecise—for example, a trigger that cannot be observed as written.0.5: The boundary is generic (“if problems occur”) or does not match the claim and the plan. 0: No boundary, or a boundary that contradicts the case facts. |
| ACT + EVIDENCE · 1 point | 1: Gives a workable action with clear limits, who is responsible, and evidence someone else can check, while distinguishing checks already completed from checks you plan to do. Partial credit: 0.75 · 0.5 · 00.75: A feasible action and useful evidence, but one element is missing—for example, the responsible role, or whether the evidence is completed or proposed.0.5: The action is vague or not feasible in the case, or the evidence cannot be inspected by someone else. 0: No action, or evidence that is invented or reported as completed when it is only proposed. |
| REFIT · 1 point | 1: Explains how the new evidence affects the initial claim and justifies RETAIN, REVISE or REPLACE with a consistent final answer. Partial credit: 0.75 · 0.5 · 00.75: The effect of the new evidence and the RETAIN / REVISE / REPLACE choice are justified, but the final record leaves one inconsistency with the new boundary.0.5: A choice is stated but not justified from the new evidence, or the final record repeats Part A without addressing the change. 0: No REFIT, or a response that ignores or contradicts the new evidence. |
Five points use the same familiar structure. The chapter artifact changes; the LMS determines how assignment points contribute to the course grade.
Learning-outcome alignment
This task supports CLO 9 of the course specification (section B). The Python build, its tests and the coverage step also support CLO 11. It is course-written practice, not an official national readiness assessment or an approved item-weight mapping.
Strong and weak answers for each criterion · how other answers are accepted
| Criterion | Strong example | Weak example |
|---|---|---|
| FIT | Strong: The concept is partial failure with at-least-once delivery: a lost reply does not mean the diagnosis was not made. Given: intermittent connectivity; the queue redelivers; the service can take 20 seconds. Assumption, marked: the service is non-deterministic. Why: Names the chapter concept, keeps to the given facts and marks the assumption. | Weak: The app just needs a better network. Why: No chapter concept; ignores the given queue guarantee. |
| FAILURE | Strong: After a timeout the app knows only that no reply arrived. The photo may have been diagnosed already. A redelivery is a new request and may get a different answer. Why: Separates no reply from no execution and names the duplicate risk. | Weak: If there is no reply, the service failed, so resend. Why: Treats a timeout as evidence of failure. |
| BOUND | Strong: The design holds while every photo carries an idempotency key and the service returns the stored result for a repeated key. Two different diagnoses for one key reopen it. Why: Names the dependency and an observable trigger. | Weak: It works unless the outage is very long. Why: No dependency and no observable trigger. |
| ACT + EVIDENCE | Strong: Action: the app attaches a photo key; the service stores the first diagnosis per key and returns it on redelivery, owned by the backend lead. Evidence: a replay test that delivers 100 photos twice and shows one diagnosis each, proposed. Why: Feasible action, a named role, evidence with its status. | Weak: Retry less often. Why: No specific action, owner or inspectable evidence. |
| REFIT | Strong: The 9% double diagnoses show my design let the model answer the same photo twice. I replace the retry path: the key is checked before the model is called, and only the stored diagnosis is shown. My first plan assumed the model would answer the same way. Why: Names what changed, chooses REPLACE with a reason, admits the first assumption. | Weak: I keep the design; the farmer can choose between the two treatments. Why: Pushes the duplicate onto the user; ignores the given fact. |
Other answers are accepted when: the answer names the chapter concept that decides, uses only the facts given in the task, separates no reply from no execution, and names evidence from a replay test or record that someone else can check. A different design that meets these conditions earns the same marks as the model answer.
The examples are about a different practice case. They show the kind of reasoning that earns the mark, not the answer to this task.
What distinguishes an unsupported answer from a stronger one?
Different practice example · weak: “Retry until it works; duplicates cannot happen.”
Stronger: For a different message service, the first action may commit before its acknowledgment is lost. A repeated identity and durable outcome record can prevent a second modeled effect; external effects need separate evidence.
The stronger answer names a mechanism, its scope and inspectable evidence. It does not certify a real system. Your assessed answer must address this task’s own facts.
The assignment in nine steps الواجب في تسع خطوات
- 115 minPrepareLecture, the two readings, the five practice questionsاحضر المحاضرة، اقرأ المصدرين، وحلّ الأسئلة الخمسة
- 21 minOpenOpen it with your Student ID, in the same browser every timeافتح الواجب برقمك الجامعي، ومن نفس المتصفح دائماً
- 320 minPart AFIT · artifact · BOUND · ACT + EVIDENCE, 120–180 wordsاكتب حكمك الأول: المشكلة، المهمة، الحدود، القرار والدليل
- 430 minBuildPlan, complete the code, write 3+ tests, Runاكتب الخطة، أكمل الكود، 3 اختبارات على الأقل، ثم Run
- 51 minCommitReview & commit Part A: it becomes read-onlyثبّت الجزء A: يصبح للقراءة فقط
- 62 minNew evidenceIt opens on the page right after you commit. Read itيظهر الدليل الجديد في الصفحة مباشرة بعد التثبيت: اقرأه
- 710 minPart BBoundary status, then RETAIN / REVISE / REPLACE and whyهل تغيّر قرارك؟ اختر وبرّر، ثم اكتب القرار النهائي
- 82 minSignDeclare AI use, type your name, tick the boxصرّح بالذكاء الاصطناعي، اكتب اسمك، وضع العلامة
- 93 minSubmitPrint / PDF, then upload the PDF in Blackboardصدّر PDF وارفعه في Blackboard
Select a step to see it on a picture of this page. Online guide: How to do an assignment.
Before you start
- Save often. Use Save draft while working and download a backup before leaving a shared device.
- Commit, then the new evidence. Part A becomes read-only when you commit, and the new evidence opens on this page straight away. Complete Part B, export the PDF and upload it in Blackboard.
- AI rules and the in-class check. Part A is written without AI. After the deadline, a 10-minute paper check on your own submission decides whether your mark stands. Read the rules for each step before you start.
New to this format? Read the step-by-step guide. The sequence preserves your first judgment; it is not a secure examination system.
AI rules and the in-class check
قواعد الذكاء الاصطناعي والتحقق في المحاضرة
FCIT Generative AI Policy, Option C (Mixed Approach). Each step below has its own permitted AI level. You remain responsible for showing your own understanding, and using AI beyond the permitted level may be treated as academic misconduct. The level of every assessment is listed in the course specification.
سياسة الذكاء الاصطناعي التوليدي في كلية الحاسبات وتقنية المعلومات، الخيار C (النهج المختلط). لكل خطوة أدناه مستوى مسموح لاستخدام الذكاء الاصطناعي. وتبقى مسؤولًا عن إثبات فهمك بنفسك، واستخدام الذكاء الاصطناعي بما يتجاوز المستوى المسموح قد يُعامل مخالفةً أكاديمية. ومستوى كل تقييم في المقرر مذكور في توصيف المقرر.
Studying the lecture before you start. AI-Assisted · for learning: AI may explain an idea and ask you to restate it in your own words. It may not answer this case.
قبل البدء: مذاكرة المحاضرة: بمساعدة الذكاء الاصطناعي · للتعلّم: يمكن للذكاء الاصطناعي أن يشرح فكرة ويطلب منك إعادة صياغتها بكلامك، ولا يجيب عن حالة هذا الواجب.
Part A answers (FIT, COMPARE, BOUND, ACT + EVIDENCE, reading, second idea). AI-Free: No AI. Write them yourself.
إجابات الجزء A: بدون ذكاء اصطناعي: بدون ذكاء اصطناعي. اكتبها بنفسك.
The AI draft in the scenario. AI-Free: It is the material you critique. Find the claims the supplied facts do not support.
مسودة الذكاء الاصطناعي في الحالة: بدون ذكاء اصطناعي: هي المادة التي تنقدها: حدّد الادعاءات التي لا تدعمها الحقائق المعطاة.
Python build. AI-Assisted: AI may explain an error message. It may not write your functions or your tests.
البناء في بايثون: بمساعدة الذكاء الاصطناعي: يمكن للذكاء الاصطناعي أن يشرح رسالة الخطأ، ولا يكتب دوالك ولا اختباراتك.
After you commit (STRESS and REFIT). AI-Assisted: AI may question your reasoning. The final decision and the words are yours.
بعد تثبيت الجزء A: بمساعدة الذكاء الاصطناعي: يمكن للذكاء الاصطناعي أن يسألك عن تفكيرك، والقرار الأخير وصياغته لك.
AI-use declaration. Required: Name the tool and the steps where you used it, what you changed because of it, and what you chose not to take, and why.
تصريح استخدام الذكاء الاصطناعي: مطلوب: اذكر الأداة والخطوات التي استخدمتها فيها، وما غيّرته بسببها، وما رفضت أخذه ولماذا.
In-class check · AI-Free. In the lecture after the deadline you answer two short questions on paper, with no devices, about your own submission: a small change to your code (which test fails, and why) and one new fact (does your decision change?). It takes about 10 minutes. Both answers correct: your assignment mark stands. One correct: your mark is halved. Neither: a two-minute conversation with the instructor decides the mark. If you miss that lecture with an accepted excuse, the check is done in office hours. This applies the ownership rule on every assignment: your written work and your own explanation must agree.
التحقق في المحاضرة · بدون ذكاء اصطناعي. في المحاضرة التي تلي موعد التسليم تجيب على ورق، وبدون أي جهاز، عن سؤالين قصيرين حول واجبك أنت: تغيير صغير في الكود (أي اختبار سيفشل ولماذا)، ومعلومة جديدة (هل يتغير قرارك؟). يستغرق نحو 10 دقائق. إذا كانت الإجابتان صحيحتين تبقى درجة الواجب كما هي، وإذا كانت إجابة واحدة صحيحة تصبح نصف الدرجة، وإذا لم تصح أي منهما تُحدَّد الدرجة بعد نقاش قصير مع الأستاذ مدته دقيقتان. ومن غاب عن تلك المحاضرة بعذر مقبول يُجري التحقق في الساعات المكتبية. هذا تطبيق لقاعدة الملكية الموجودة في كل واجب: يجب أن يتفق ما كتبته مع شرحك له.
Identity
Loaded from the entry page. Drafts are separated by Student ID in this browser.
Submission details
Check the current deadline and submission instructions in the LMS.
How this assignment connects to the lecture and the five objectives
ONE METHOD · TWO DIFFERENT CASES
From the classroom card to this assignment
The lecture has 20 slides and three short practice stations: claim + evidence; mechanism + limits; changed condition + revised decision. Here you transfer that reasoning to the separate assessed scenario below. Do not copy the practice answer or submit another full classroom report.
Unchanged: 5 raw points, existing deadline, local draft identity, confirmed Part A commitment, STRESS then REFIT, AI declaration and Blackboard submission. Already completed work does not need repeating merely because the lecture was updated.
Five chapter objectives → existing evidence opportunities
These are local chapter objectives. They do not renumber the approved syllabus outcomes or establish an official national mapping. The lecturer judges correctness and sufficiency; a field being filled is not attainment.
| Chapter objective | Where it is practised / evidenced within this task |
|---|---|
| Objective 17.1 Explain distributed-system design issues. | FIT |
| Objective 17.2 Compare RPC and message-based interaction. | transfer question + interaction trace |
| Objective 17.3 Distinguish layers and tiers. | source application + architecture |
| Objective 17.4 Choose among the five source architectural patterns. | FAILURE + lab record |
| Objective 17.5 Explain SaaS configuration, multi-tenancy and scaling. | transfer question + BOUND + REFIT |
2 · PART A · 20 MINUTES
Assessed scenario · fictional teaching case
Task format: Review an AI assistant’s answer. The same five criteria apply.
A fictional event-booking system has three parts: a browser, an application service that handles requests, and a database that stores bookings.
- The browser sends a booking request through the service. If no reply arrives before the waiting time ends (timeout), the browser sends the request again with a new request ID.
- The database creates one reservation for each new request ID.
- Normal requests have succeeded. Nobody has tested what happens if the database saves a booking but the reply is then lost.
Recommend how these parts should work together in a trial, and the rule for sending a request again (retry).
An AI assistant's draft answer — review it; do not copy it: “Keep the current design. Normal requests succeed, so the booking flow is reliable. Sending the request again with a new request ID is safe, because the database creates exactly one reservation for each request ID. If a reply is lost, the browser's retry fixes the problem. A longer timeout would remove the risk completely.”
Quick word help · معاني المصطلحات
شرح مختصر للكلمات المستخدمة في هذا الواجب. ارجع إليه أثناء الحل.
Words in this case
- Request ID
- A value used to identify one request.
قيمة تميز طلبًا محددًا عن غيره. - Idempotence
- Repeating the same request does not create an extra effect.
إعادة الطلب نفسه لا تنتج أثرًا إضافيًا مثل حجز ثانٍ. - Commit
- Here, saving the database change; on this page, locking Part A.
في قاعدة البيانات: تثبيت التغيير. وفي صفحة الواجب: تثبيت الجزء A. - Persistent / durable storage
- Saved records that remain after the service restarts.
سجلات محفوظة تبقى بعد إعادة تشغيل الخدمة. - Atomic save
- Related changes are saved together: all succeed or none does.
حفظ تغييرات مترابطة كوحدة واحدة: تنجح كلها أو لا يحفظ أي منها. - Reconciliation
- Checking and comparing records to resolve missing or conflicting outcomes.
مراجعة السجلات ومقارنتها لحسم النتائج المفقودة أو المتعارضة.
Words used in every assignment
- FIT
- What problem matters, and why?
ما المشكلة المهمة؟ ولماذا؟ - BOUND
- When does your recommendation apply? What would make you review it?
متى يصلح قرارك؟ وما الذي يستدعي مراجعته؟ - ACT + EVIDENCE
- What will you do, who is responsible, and what supports it?
ما الإجراء؟ ومن المسؤول؟ وما الدليل؟ - STRESS
- New information shown after you lock Part A.
معلومات جديدة تظهر بعد تثبيت الجزء A. - REFIT
- Review your decision using the new information.
راجع قرارك في ضوء المعلومات الجديدة. - RETAIN / REVISE / REPLACE
- Keep the decision / adjust it / choose a different decision.
أبقِ القرار / عدّله / استبدله بقرار آخر. - Fact / assumption / proposed
- Given evidence / something you assume / something you suggest doing or testing.
حقيقة معطاة / افتراض يحتاج تحققًا / إجراء أو اختبار تقترحه. - Artifact
- The work you produce: for example a test plan, comparison or set of rules.
المخرج الذي تعدّه، مثل خطة اختبار أو مقارنة أو مجموعة قواعد. - Transfer answer
- Apply a second chapter idea to the question, using your own explanation.
طبّق فكرة ثانية من الفصل على السؤال، واشرحها بأسلوبك. - Mutation test / micro-viva
- Your tests try code with known bugs / a short discussion where you explain and change your code.
اختباراتك تكشف أخطاء مقصودة في الكود / مناقشة قصيرة تشرح فيها كودك وتعدله.
Keep the written response to about 120–180 focused words; use compact tables or notation. Include the source application and transfer answer in that budget. Your Python code, tests and build record are not counted in it. State facts, assumptions and proposed evidence separately. Quote or cite the assigned source precisely; explain its role. Report actual study time at the end.
A1 · FIT · 1 POINT
State what the browser, application service and database each do, and where they run (deployment tiers). Identify where a request crosses between computers. Explain the difference between receiving no reply and the server doing no work. Name one claim in the AI draft that the supplied facts do not support, and the fact that shows it.
PYTHON BUILD · ASSESSED IN FAILURE
Build a service that handles repeated requests safely
Write BookingService.reserve so that one user action creates at most one reservation. It must still do this when a reply is lost, the app sends the request again, or the service restarts. This property is called idempotence. Write tests that reproduce these failures.
First time? Try the not-assessed practice build and a complete worked example on How to do an assignment.
Budget about 30 minutes. Python runs in your browser: nothing to install, and nothing is uploaded. The first run downloads Python once (about 10 MB, internet needed). Passing every check is necessary, not sufficient: your written record must use what the build shows.
Your tests also run against versions of the code with known bugs. Each bug must make at least one of your tests fail. This is called mutation testing. Your build record gives you a small code change to explain in a short discussion (micro-viva), selected using your Student ID. Be ready to make it and explain which tests change and why.
Primary source · about 15 minutes: P. Helland, “Idempotence Is Not a Medical Condition,” ACM Queue 10(4), 2012. Read why a message may need to be sent again, and how a unique request ID can make that retry safe. Which of your tests reproduces the retry described in the article? Use the answer in your build plan.
The course checks your build must pass
- different actions create different reservations
- the same request id books once and returns the same id
- a retry after a lost reply does not book twice
- the outcome survives a restart
- a missing request id is rejected
- your own tests: at least three, all passing
- your tests catch every known bug (mutation test)
Keep the given names. Write at least three functions whose names start with test_. Tab inserts four spaces.
Write your plan, then run.
COVERAGE STEP · COURSE OUTCOME 11 · DESIGN AND IMPLEMENT TEST CASES ACROSS TESTING STRATEGIES
The build record measures which lines and branches of your code your own tests run. The course checks are not counted.
- Make your three tests pass and read the coverage lines in the build record.
- Change one input in one of your tests. Run again: the record shows Run 2.
- Write one sentence: which branch is still not tested, and which input would test it.
RUN 3 · THEIR CHANGE · A PART YOU DID NOT WRITE CHANGES
The remote app ships a new release. After a lost reply it sends the same booking again, but with a new request_id.
- retry after a lost reply: send the same request_id + retry after a lost reply: send a new request_id
After your tests pass (Run 2), run their change. Do not edit your code or your tests first.
A2 · FAILURE · 1 POINT
List the events in order when a booking is saved but its reply is lost. Propose a rule for retrying or checking the saved records, and a test that would reveal a duplicate booking. State what you are assuming. Use your actual build record to explain a difference between the original and corrected behavior, one limit of the model, and any prediction you corrected.
Use your executed test log above. Explain one observed difference between models and one limit of the model; revise an incorrect prediction explicitly. The log replaces prose about tests you might run.
A3 · BOUND · 1 POINT
Name the kinds of failure your recommendation covers and the rule the stored bookings must still satisfy (consistency requirement). Say what the supplied tests do not cover.
A4 · ACT + EVIDENCE · 1 POINT
Recommend an action for the trial and state its limits. Name who is responsible. Explain how your design works and what results you need before allowing the browser to retry automatically.
Name the test, activity record or review that supports your decision. State the conditions it covers, who checks it, and what evidence is missing. Clearly separate results already available from checks you are only proposing.
ASSIGNED SOURCE APPLICATION · INCLUDED IN THE EXISTING RUBRIC
Give a slide number from the assigned reading. Explain its idea in your own words, then point to the part of your answer it supports or challenges. A slide number alone is not enough.
TRANSFER CHECK · SCORED WITH FIT
SaaS means providing software to users over the internet. Service-oriented architecture means organizing software as services that communicate. Explain how these ideas differ and why one system can use both. Give one concern about keeping different customer organizations' data separate (tenant isolation).
Commit is not LMS submission. Confirmation freezes FIT, FAILURE, BOUND, ACT and EVIDENCE before the new information appears.