S90-09 SOA Design and Architecture Lab: Applying Architecture Patterns Under Constraints

S90-09 is a historical Arcitura exam code associated with the SOA Design and Architecture Lab. In Arcitura’s current Service Technology curriculum, the corresponding lab subject is presented as Module 08, SOA Design & Architecture Lab with Services & Microservices. The current material is explicitly exercise-oriented and asks learners to apply architecture models and design techniques to realistic problems.

That makes this source page different from the conceptual pages that precede it. S90-01 provides foundational principles, S90-03 develops service design, and S90-08 introduces advanced mechanisms. The lab should test whether those ideas can be combined under conflicting constraints rather than whether a candidate can repeat definitions.

Arcitura Education now frames the lab in a modern services-and-microservices context. Candidates using the historical S90-09 identifier should therefore practice with current distributed architectures while preserving the original discipline of explaining boundaries, contracts, composition, integration, and pattern choices.

Start every lab by extracting constraints before proposing components

Architecture exercises often hide the real problem inside requirements. Identify latency targets, consistency needs, regulatory rules, ownership boundaries, expected scale, failure tolerance, legacy dependencies, and delivery deadlines before drawing a solution. A pattern that is elegant in isolation may violate one of those constraints.

Write the non-negotiable conditions separately from preferences. “Must not expose card data” is different from “team prefers REST.” This prevents familiar technologies from becoming assumptions and gives the design a basis for evaluating trade-offs.

Define service candidates around capability and change

List business capabilities and identify which ones have distinct rules, owners, data, and rates of change. Then propose service boundaries and challenge them. If two services require synchronized releases or direct database access into each other, the boundary may be artificial.

The lab should also identify reusable and task-specific capabilities. Not every process deserves a universal service. A candidate should explain why a capability is expected to serve multiple compositions or why it is intentionally scoped to one workflow.

Turn contracts into concrete compatibility decisions

For each public service, define what the consumer can rely on: request shape, response semantics, error behavior, security context, and version policy. Then introduce a change such as a new required field or renamed concept and decide how old consumers continue working.

A good lab answer shows a migration strategy rather than saying “version the API.” That may include additive evolution, parallel endpoints, adapters, deprecation telemetry, and a retirement window tied to observed consumer adoption.

Model one end-to-end composition including failure

Choose a business flow and map each step, participant, state change, and side effect. Then mark which operations are reversible, which can be retried, and what happens if the third step fails after the first two have committed.

The candidate should decide whether a central orchestrator, event choreography, or hybrid control model best fits the process. The answer should include compensation or reconciliation for partial success and should explain how operators determine the current state during an incident.

Use messaging only where delayed coupling is acceptable

Asynchronous communication can improve resilience and burst handling, but it changes user expectations and failure semantics. Apply the messaging concepts from S90-02 to decide which interactions can wait and which require immediate confirmation.

For every queue or event stream, define duplicate handling, ordering assumptions, retry policy, dead-letter treatment, and monitoring. A lab answer that says only “use a message bus” is incomplete because the difficult behavior starts after the message enters the bus.

Introduce intermediaries with an explicit responsibility boundary

If the design includes an API gateway, broker, transformation layer, or legacy wrapper, state exactly what responsibility it owns. Cross-cutting authentication or routing may belong at a gateway, while business rules should remain with domain services.

The lab should also include failure behavior for shared intermediaries. What happens when the gateway is unavailable? Can messages accumulate safely if a downstream system is offline? Is the transformation layer versioned with both sides? These questions reveal whether the intermediary is helping or merely moving complexity.

Assign authoritative data ownership and replication rules

Each important business entity should have a clear authoritative owner. Other services may keep read models, caches, or replicated projections, but the design must explain how those copies are updated and what consistency users should expect.

Challenge the architecture with a data disagreement. If two services report different customer status, which one is correct? How is the conflict repaired? A service-oriented architecture that cannot answer those questions has hidden ownership ambiguity.

Add security and observability before declaring the design complete

Define identities for users and services, authorization at capability boundaries, protection for secrets, and rules for sensitive data. Then add correlation IDs, distributed traces or equivalent transaction visibility, service metrics, logs, and ownership metadata.

Operational evidence should map to the architecture. If a composition fails, operators should be able to identify the failing participant and the last successful business step. If access is denied, the audit trail should show which identity and policy caused the decision.

Finish by defending trade-offs and testing a change scenario

A lab solution is not complete until the candidate can state what was intentionally sacrificed. Perhaps eventual consistency was accepted to isolate failure, or a gateway was introduced to centralize policy at the cost of shared infrastructure. Naming the trade-off demonstrates understanding.

Then apply a future change: double the traffic, move one capability to another team, add an external partner, retire a legacy system, or introduce a new contract version. Explain which parts of the architecture change and which remain stable. That is the most direct test of whether service orientation actually reduced the cost of evolution.

Candidates should practice several different domains rather than memorizing one reference design. An e-commerce flow, insurance claim, booking platform, and employee onboarding process expose different consistency and ownership pressures. The principles stay similar while the correct architecture changes with the constraints.

Review each lab as if another team will operate it. Are ownership and failure modes clear? Can the design be monitored? Can a consumer migrate between contract versions? Can the system recover from duplicate events or partial completion? If the answer depends on a human remembering undocumented steps, the design is not yet mature.

S90-09 is best understood as a legacy label for applied architectural judgment. The current Arcitura lab has evolved toward services and microservices, but the central skill remains the same: turn abstract service-orientation principles into a defensible design that survives change, partial failure, and real organizational boundaries.

One strong lab variation is to impose an acquisition or merger scenario. Two organizations have overlapping customer services, different identity systems, incompatible message formats, and separate operational teams. Design a staged integration that delivers business value before full platform consolidation. This forces the candidate to use wrappers, translation, canonical concepts, or shared gateways carefully while preserving clear ownership during transition.

Another useful exercise is a reliability budget. Give the system a target availability and a recovery-time objective, then ask which dependencies can realistically meet them. If a critical composition depends synchronously on a lower-availability service, the design must add fallback behavior, asynchronous decoupling, replication, or a revised business promise. The lab becomes more realistic when service-level claims are checked mathematically against dependencies instead of written as aspirations.

After finishing a solution, conduct a red-team architecture review. Look for shared databases, universal administrator credentials, infinite retry loops, silent schema assumptions, single points of routing failure, and components that no team clearly owns. Then simplify. The best lab submissions often improve when one unnecessary intermediary or shared dependency is removed, because the resulting architecture is easier to understand and operate.

A final exercise should compare two valid designs rather than one good design and one obviously bad design. For example, solve the same workflow once with explicit orchestration and once with event choreography. Score both against observability, team autonomy, latency, regulatory evidence, recovery complexity, and expected change. The goal is to defend a context-sensitive choice, not memorize a preferred pattern.

Lab reviews should include deployability. A design may be architecturally sound but impossible to release safely if every service requires a coordinated cutover. Identify which components can be deployed independently, what compatibility period is required, how database changes are sequenced, and which feature flags or routing controls support gradual migration. This connects design quality directly to delivery risk.

A concise decision log strengthens the lab further: record the rejected alternatives, the constraint that ruled each one out, and the evidence that would cause the team to revisit the decision later. This keeps architecture adaptable instead of treating the first design as permanent.

Before finishing a lab, perform a short architecture review from three perspectives. The consumer should be able to explain the contract and expected failure behavior without knowing private implementation details. The service owner should be able to identify authoritative data, dependencies, scaling limits, and rollback options. The operator should be able to locate telemetry, trace a failed transaction, distinguish a dependency outage from an application defect, and recover without bypassing governance. If any perspective depends on undocumented tribal knowledge, revise the design. This final review makes the lab more realistic because a production architecture must remain understandable not only when it is drawn, but also when different teams change it, operate it, and troubleshoot it under pressure.