MAL Hackathon · Participant field guide
Make choices that fit your problem. Understand the qualities your system needs, the principles behind your design and the evidence that supports your decisions.
Start with the problem
Quality attributes describe outcomes. Reliability, scalability and performance describe what your system should achieve. Design principles guide your choices about responsibilities, dependencies and change.
This is a reference, not a requirement to implement every item. Working code is optional; diagrams, contracts, example data and reasoned walkthroughs can demonstrate your design.
As a useful exercise, choose three priority attributes for your assigned problem. For each, explain:
Always address the stated business rules and relevant security and privacy concerns. Identify assumptions and distinguish proposed behavior from behavior you have actually verified.
01 · Outcomes that matter
These examples use reimbursement claims. Apply the same questions to Healthtech appointments, Mumbai property workflows or Martech approvals.
Does the system enforce the business rules?
Example: An approved reimbursement cannot exceed the claimed amount.
Walk through allowed and rejected amounts, boundary values, and invalid state transitions. Identify which component enforces the rule.
What changes as users, records or requests increase?
Example: Fetch claim history in pages and index the service-side queries used most often.
State an expected workload, identify the likely bottleneck and explain what would change at ten times the load. Pagination alone does not prove scalability.
Is the experience responsive without wasting battery, bandwidth or memory?
Example: Compress receipt images before upload and keep expensive work off the app’s main thread.
Choose a target device, network condition and response-time goal. Explain how you would profile frame delays, upload latency or memory use.
Can users trust an operation to produce its intended result?
Example: Retrying the same claim submission does not create duplicate claims.
Walk through repeated requests, lost responses and app restarts. Show where a submission identifier is stored and where uniqueness is enforced.
What remains usable when a dependency is unavailable?
Example: Users can read saved claims while the approval service is down, with a clear last-updated indication.
Mark which features remain available, which become read-only and which must stop. Do not imply cached data is current.
How does the system handle interruptions and recover?
Example: An interrupted upload remains pending and retries with bounded backoff.
Identify retry limits, timeouts, persisted pending state and user feedback. Explain what happens if the app closes before recovery.
Who owns authoritative state, and how are conflicts resolved?
Example: Two reviewers cannot move a claim into conflicting final states.
Trace simultaneous updates and stale reads. Explain version checks or transactions at the authoritative service, and how the app reconciles a rejected update.
Who can perform each action, and what information needs protection?
Example: The service enforces reviewer permissions, and receipt contents stay out of diagnostic logs.
Describe trust boundaries, access checks, storage protection and data retention. You may simulate roles without building a login screen; explain production controls separately.
How safely can the team change the system?
Example: Updating reimbursement policy does not require rewriting screens or storage code.
Pick a realistic policy change. Name the modules and contracts affected, the tests that protect existing behavior and any data migration needed.
Can important behavior be verified in isolation?
Example: Approval rules can be checked with a fake repository and a controlled clock.
Write example inputs and expected outcomes for a business rule and a recovery scenario. Automated tests are welcome if you build code; a clear test design is useful evidence too.
How would you discover and diagnose a failure?
Example: A correlation identifier connects an app upload failure to a service request without exposing personal data.
Define useful events, metrics and diagnostic fields. Show how they distinguish a network failure from a validation rejection, without logging sensitive payloads.
Can people with different abilities complete the core journey?
Example: Claim status has a text label, errors are not communicated by color alone, and controls have screen-reader names.
Walk through the flow using a screen reader, larger text and keyboard or switch navigation where supported. Explain how focus moves after an error.
Can the team afford, deploy and operate this design?
Example: Limit receipt upload sizes, plan data recovery and describe how a faulty release would be rolled back.
Identify the main cost drivers, configuration and deployment boundaries, backup responsibilities and a recovery plan. Avoid adding services without a clear benefit.
02 · Choices behind the diagram
Keep presentation, business rules and data access in distinct responsibilities. A screen should not own reimbursement policy.
Keep related behavior together and dependencies deliberate. A policy change should not force unrelated modules to change.
Define inputs, outputs, errors and ownership between components. State what “submit claim” guarantees and what it can reject.
Let core rules depend on interfaces rather than a particular database or network client. Supply a different implementation for testing.
Use the least complex design that meets the requirements. Every layer, service and tool needs a reason.
Isolate likely sources of change, such as approval policies or external providers. Avoid abstracting everything in advance.
State what your choice improves, what it costs and when you would revisit it. Offline access, for example, adds synchronization and conflict-handling work.
03 · Show the reasoning
A sequence diagram, interface contract and example data can prove that you have thought through the scenario. Label any simulation; claim only guarantees your evidence supports.
04 · Use it in your defence
This guide explains the concepts behind the published criteria. It does not add scoring categories or change their weights.