Microservice architecture separates business capabilities into independently operated services that communicate through APIs or events. It supports acceptance testing without driving the user interface, reducing browser overhead while exercising service behavior directly. section 13.0 section 13.4
A frequent-flyer registration flow illustrates the arrangement: a membership service creates a pending account, requests a token, publishes an event, and lets an email service send confirmation. Authentication and membership services then support login and account access. section 13.4
The registration process crosses service boundaries in this order:
- POST registration details to the Frequent Flyer endpoint. section 13.4
- Create a pending membership account and obtain a single-use token from the token service. section 13.4
- Publish a NewFrequentFlyerEvent through a message broker so the email service can prepare confirmation. section 13.4
- Confirm the email through a POST endpoint, activate the account, and use authentication and membership endpoints for login and account details. section 13.4
Acceptance scenario
Given Tracy does not have a Frequent Flyer account, when she registers and confirms her email address, then she should have a new Standard tier account with 0 points. section 13.4
Use the architecture diagram to trace requests, events, tokens, and responsibilities across the membership, email, authentication, and token services. section 13.4
