Community Platform: Interview Demo Notes

Architecture Diagram

This section uses a static diagram image for presentation stability. The editable diagram source stays versioned in src/architecture-diagram.md.

60-Second Intro

1. Problem: We needed to move from manual moderation to user reporting with strict business rules.
2. Architecture: I split ownership into three Azure Function services: forum, moderation, and user.
3. Integration: I used Azure Service Bus for asynchronous, event-driven updates between services.
4. Result: The demo shows both public forum usage and admin moderation workflows, with business rules enforced in backend data logic.

Requirement 1 Solution

A user can report another user only once.

1. Owning service: Only moderation-functions handles POST /api/reports, so the reporting rule has a single owner.
2. Azure SQL enforcement: Table moderation.Reports has a unique constraint on (ReporterUserId, TargetUserId).
3. Runtime behavior: First report inserts normally; duplicate report from the same reporter to the same target is rejected by the database and mapped to a validation/duplicate API response.
4. Concurrency safety: Even if two duplicate requests arrive close together, SQL guarantees only one row is accepted.
5. Event publication: For accepted reports, moderation publishes report-created on Service Bus for downstream processing.

Requirement 2 Solution

When a user receives 5 reports, the account must be blocked.

1. Count source: moderation-functions counts unique reports per target user from moderation.Reports.
2. Threshold logic: At 5+ reports, moderation publishes user-threshold-reached (event contract: UserReportThresholdReached).
3. Owning service for account state: user-functions consumes the queue and updates users.Users to Status=Blocked with BlockedAt.
4. Idempotency: Re-delivered threshold events do not corrupt state; blocking logic is safe to run more than once.
5. Audit event: After blocking, user-functions publishes user-blocked (contract: UserBlocked) for observability and downstream reactions.

Azure Resources Used Per Requirement

1. Azure Static Web App: Hosts the forum/admin frontend and sends report requests to backend APIs.
2. Azure Functions - moderation-functions: Owns report ingestion, uniqueness enforcement path, and threshold detection logic.
3. Azure SQL Database: Persists reports and users; unique constraints enforce correctness under concurrent traffic.
4. Azure Service Bus: Carries report-created, user-threshold-reached, and user-blocked events between service boundaries.
5. Azure Functions - user-functions: Consumes threshold events and applies idempotent account blocking.
6. Application Insights: Captures exceptions and traces so event flow and failures are diagnosable during demo and operations.
7. Key Vault + app settings pattern: Securely injects sensitive values like Service Bus connection into Function apps in deployment pipelines.

End-to-End Data Flow

1. Step 1: Forum user creates a post (forum-functions writes to forum schema in Azure SQL).
2. Step 2: Another user reports the post via POST /api/reports (moderation-functions writes to moderation.Reports).
3. Step 3: Unique constraint guarantees one report per reporter-target pair.
4. Step 4: moderation-functions publishes report-created and evaluates report count.
5. Step 5: At threshold, moderation publishes user-threshold-reached on Service Bus.
6. Step 6: user-functions Service Bus trigger blocks the user in users.Users and publishes user-blocked.
7. Step 7: Admin pages fetch updated reports and blocked users to show current moderation state.

Keep domain logic where it belongs: forum owns posts, moderation owns reports and thresholds, users owns account status.

Technical Proof Points To Show Live

1. Proof for requirement 1: Show SQL constraint/index screenshot and a duplicate report API rejection in the UI response panel.
2. Proof for requirement 2: Show fifth report, then show user status as Blocked in users data and admin users page.
3. Proof of event-driven architecture: Show Service Bus queues and logs/traces for threshold and blocked events.
4. Proof of ownership boundaries: Explain why forum does not block users directly and why moderation does not own user state.

What To Say About Tradeoffs

• POC choice: One SQL database, separate schemas and DbContexts for faster delivery.
• POC choice: Real event-driven flows implemented before advanced hardening.
• Production next step: Add deeper automated tests and outbox-style delivery guarantees.
• Production next step: Replace demo role switch with full auth and role claims integration.

Likely Questions + Short Answers

• Why microservices? To align ownership and avoid coupling moderation rules into forum code.
• How do you prevent duplicate reports? Unique DB constraint and service-level validation.
• Why Service Bus? It supports asynchronous boundaries and at-least-once message patterns.
• How do you handle duplicate events? Idempotent consumers, especially in user blocking flow.

Screenshot Placeholders

Use these as visual anchors while speaking. Replace with screenshots from your environment.

• Database Constraint: Screenshot of moderation.Reports unique index on (ReporterUserId, TargetUserId).
• Threshold Event: Screenshot of moderation report count and threshold publish log/output.
• Blocked User: Screenshot of users.Users row showing Status=Blocked and BlockedAt timestamp.
• Admin View: Screenshot of admin pages showing reports, decisions, and blocked users list.

Demo Run Order

1. Open forum page, create a post.
2. Report once from one user.
3. Try duplicate report from same user and show rejection.
4. Submit additional unique reports until five total.
5. Show blocked status and explain the Service Bus threshold event path.
6. Open admin pages and close with architecture/tradeoff summary.