Final Assessment

An integrative assessment covering every topic in the course — design a complete architecture from requirements through to operations.

Objective

This final assessment brings together all the concepts covered in the previous sections: fundamentals, architecture, patterns, flows, security, observability, deployment, and versioning. Your task is to design a complete architecture for a real system.

There is no single correct answer. What matters is the quality of your reasoning, the consistency of your decisions, and your ability to justify each choice.

The project: HealthTrack

Description

HealthTrack is a telemedicine platform that connects patients with doctors for virtual consultations. The platform must handle:

• Registration and profiles for patients and doctors
• Scheduling and appointments with real-time availability
• Video calls for virtual consultations
• Medical records with documents and prescriptions
• Payments per consultation with multiple methods
• Notifications via email, push, and SMS
• Reports for administrators and doctors

Non-functional requirements

Part 1: Architectural style (Fundamentals)

Questions

1. Which architectural style would you choose? Monolith, microservices, or hybrid?
2. How would you split the system into domains/services?
3. How would you assign the squads to the domains?

Evaluation criteria

• Clear justification of the chosen style
• Domain split that is consistent with the business
• Consideration of team size and timeline

Part 2: Component architecture (Architecture)

Questions

1. Draw a high-level diagram with the main components
2. How do the services communicate with one another?
3. Do you need an API Gateway? A BFF?
4. Where does the video call logic live?

Evaluation criteria

• Clear diagram with components and connections
• Justification of sync vs async communication
• Consideration of external services (video, payments)

[Mobile/Web App]
    │
    ▼
[API Gateway + Auth]
    │
    ├──► [Users Service]           ──► [PostgreSQL]
    ├──► [Appointments Service]    ──► [PostgreSQL + Redis]
    ├──► [Consultations Service]   ──► [PostgreSQL + S3]
    ├──► [Payments Service]        ──► [PostgreSQL]
    │
    └──► [Event Bus (RabbitMQ/Kafka)]
            │
            ├──► [Notifications Service]
            └──► [Analytics Service]

[Video Service: Twilio/Agora] ← external integration

Part 3: Applied patterns (Patterns)

Questions

1. Which resilience patterns would you apply, and where?
2. Would you use a Saga for the appointment booking + payment flow? Orchestrated or choreographed?
3. Where would you apply CQRS? Is it necessary?
4. How do you guarantee idempotency in payments?

Evaluation criteria

• Resilience patterns applied correctly
• Justification of orchestrated vs choreographed Saga
• Idempotency in critical operations

Part 4: Security (Security)

Questions

1. How do you handle authentication and authorization?
2. How do you protect sensitive medical data?
3. What security measures do you apply at each layer?
4. How do you handle patient consent for accessing their records?

Evaluation criteria

• Robust authentication (MFA for doctors)
• Encryption of sensitive data at rest and in transit
• Granular access control (RBAC or ABAC)
• Regulatory compliance considered

Part 5: Observability (Observability)

Questions

1. Which business and technical metrics would you collect?
2. How would you implement distributed tracing?
3. Which alerts are critical for this system?
4. What dashboard does the on-call team need?

Evaluation criteria

• Relevant business metrics (completed appointments, cancellation rate)
• End-to-end tracing implemented
• Alerts prioritized by user impact

Part 6: Deployment and operations (Deployment)

Questions

1. How would you deploy the services? Kubernetes, serverless, PaaS?
2. What is your CI/CD strategy?
3. How do you handle configuration and secrets?
4. What is your scaling strategy?

Evaluation criteria

• Deployment strategy consistent with the architecture
• Automated CI/CD with quality gates
• Secrets managed securely
• Scaling defined for the critical components

Part 7: Versioning (Versioning)

Questions

1. How do you version the APIs between services?
2. How do you handle breaking changes?
3. What versioning strategy do you use for events?

Evaluation criteria

• Clear versioning strategy (URL, header, or content negotiation)
• Plan for breaking changes with no downtime
• Event versioning considered

Deliverable

Your assessment must include:

1. Architecture document (1-2 pages): component diagram, key decisions, and justifications
2. Flow diagram for the main use case: book appointment → pay → hold consultation
3. List of trade-offs: what you sacrificed and why
4. Migration plan: how you would get from the MVP to the complete architecture

Rubric

Final reflection

By completing this assessment, you will have practiced the full architectural design process — from requirements through to operations. This is the same process you would follow on a real project.

Remember: architecture is not a static document. It is a set of decisions that evolve with the system, the team, and the business. What matters is not getting everything right from the start, but having a solid process for making decisions and adapting when things change.