Required Architecture Overview

Trace one job through the required RabbitMQ-only service boundary and its evidence

Overview

  • Required service roles
  • RabbitMQ internal boundary
  • Jobs and correlation
  • Transformed data and runtime evidence

Before this lesson, use the instructor-provided team repository and project board; connect assigned Issues to task-branch pull requests and obtain teammate approval before merge. Review Local Git Workflow And Course Repositories for the Git commands

RabbitMQ Is The Internal Boundary

  • The app server handles the user-facing workflow and publishes internal work
  • RabbitMQ routes predictable messages to the service responsible for that work
  • Workers consume jobs, perform service-specific processing, and publish results or errors
  • The database role stores user data and transformed project data through the queue-centered service path
  • External API responses are cleaned into fields the project needs, not stored as raw dumps
  • Git and GitHub can hold code and change history; they do not replace runtime routing, promotion, or availability tooling

Compare the roles and message contract below

Required Roles And Boundary

IT490 systems integration architecture diagram

  • The diagram fixes the App, RabbitMQ, API worker, and database service roles and the queue-only internal communication boundary
  • The named PHP app and the visual placement are illustrative; use the approved products and topology for the team project

Separate Constraints From Choices

Mandatory course constraintTeam design choice
App, RabbitMQ, API worker, and database service responsibilities remain separated across the required architectureApproved backend and database products
Internal VM-to-VM requests, results, status, and errors cross RabbitMQAdditional workers, queue topology, and service grouping
Stored external data is transformed into project-relevant fields rather than kept as a raw API dumpWhich approved API and fields support the user workflow
Evidence must show the behavior, failure state, and recovery across the queue boundaryLog labels, diagram notation, and recovery details not fixed by an assignment
  • Docker and container substitutes do not replace required manually configured course infrastructure

Job And Message Contract

  • A job is a small request for another service to perform a specific action
  • A predictable request identifies the action, the data needed by the consumer, and a way to correlate the result
  • Names such as type, payload, and correlationId are one acceptable message shape, not required field names
  • A success or error result must remain traceable to the original request
  • This queue contract reduces direct service coupling and lets work wait for an available consumer

Worked Example: Fetch Player Stats

This fictional path demonstrates the required boundary. Its job name, fields, and service labels are examples rather than a project template

  1. App publishes an illustrative fetch_player_stats job with playerId and a new correlationId
  2. RabbitMQ routes the job to the API worker
  3. API worker calls the external API and transforms only the project fields
  4. API worker publishes the transformed result with the same correlationId through RabbitMQ
  5. Database service consumes the storage request, writes the cleaned record, and publishes an acknowledgement
  6. App receives the correlated success or error through RabbitMQ and updates the user-facing workflow

Follow the matching evidence below

Follow One Correlation ID

BoundaryObservable evidence
App to RabbitMQPublish observation with the team's action and correlation labels
RabbitMQ to API workerQueue, binding, consumer, and delivery state
API workerConsume log, external response status, transformed field count
Worker to database serviceCorrelated storage request and acknowledgement through RabbitMQ
DatabaseQuery showing the cleaned project record
Result to appCorrelated success or error displayed in the workflow
  • One correlation value should connect the entire evidence set; the field name is a team choice unless an assignment fixes it

Troubleshoot The Flow

  • Success: Evidence shows the same correlation ID at publish, routing, worker processing, storage, and app result
  • Failure test: Stop the API worker, submit the job, and capture the queued or retryable state plus the app's pending/error status
  • Recovery: Restart the worker and show the job completing without a direct app-to-worker fallback
  • Hard boundary: Any direct internal VM request, direct fallback, or raw API dump fails the required architecture
  • Keep screenshots or logs readable enough to prove role, timestamp, state, and correlation

Knowledge Check

Questions

  1. What must carry internal requests, results, status, and errors between project VMs?
  2. What connects a job request with its result or error?
  3. Why does the database service store transformed external data rather than a raw API dump?

Answers

  1. RabbitMQ carries those messages; direct internal VM requests do not meet the required boundary
  2. A correlation value shared by the request and its result or error
  3. The project stores the relevant fields needed by its user workflow

Use Next to reveal each answer

Key Terms And Further Learning

  • Producer: publishes a message for another service
  • Consumer: receives and processes a routed message
  • Correlation value: connects a request to its success or error result
  • Further learning: RabbitMQ tutorials and reliability guide

Summary

  • The app, workers, and database service communicate across internal VM boundaries through RabbitMQ
  • A predictable team-defined message contract and correlation value make the workflow observable; the example field names are not prescribed
  • The architecture evidence must prove routing, processing, transformed storage, failure, and recovery
  • Before milestone implementation, the team should be able to name each role, expected job, data boundary, and evidence path

Next presentation: Architecture Planning And VM Communication Practice