4.4 Modernization and Enhancements
Official task mapping
SAP-C02 task 4.4: Purpose-built and integration knowledge; incremental decoupling and platform modernization. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.
Prerequisites
Review target selection, integration patterns and DynamoDB modeling. Be able to explain the relevant failure boundary and access/cost model before choosing a service.
Modernize against a measured problem
Use strangler-style replacement to move bounded capabilities behind a stable interface. Identify data ownership and transaction boundaries before splitting a monolith. Containers can improve packaging without changing application architecture; serverless can reduce infrastructure management but does not remove quotas, cold-start, timeout or cost concerns.
Step Functions coordinates supported workflows with explicit retries/timeouts; SQS buffers work, SNS fans out and EventBridge routes events. Match orchestration versus choreography to visibility and coupling needs. Do not call SWF universally unsupported simply because it is older; evaluate actual workflow requirements and supported contracts.
RDS/Aurora may reduce administration if compatibility and licenses fit. Heterogeneous conversion needs assessment of SQL, stored code, extensions and application behavior. DynamoDB requires access-pattern/key design and transaction/consistency decisions; it is not a drop-in relational database. Serverless scaling does not fix a poor query or remove every cost.
Modernization alternatives and boundaries
| Change | Potential benefit | Evidence required |
|---|---|---|
| EC2 database → RDS | Managed operational features | Engine/extensions, privileges and recovery fit |
| Compatible relational workload → Aurora | Suitable scaling/availability/I/O model | Benchmark and full cost comparison |
| Licensed engine → compatible open engine | Possible license/operating reduction | Stored code, SQL, conversion and legal review |
| Relational access → DynamoDB | Suitable key-based scale | Explicit access patterns, indexes and invariants |
| Monolith worker → container | Packaging/deployment consistency | Dependencies, runtime and orchestration need |
| Event worker → Lambda | Managed event capacity | Supported execution model and total cost |
Step Functions offers explicit state/retry/timeouts with Standard/Express differences. SWF has its own worker/decision workflow model; compare actual duration, event and integration requirements rather than “old means unusable.” SQS/SNS/EventBridge can support choreography, but a multi-step business process may need explicit state and compensation.
The outbox design reduces the database/message dual-write gap; it still requires publisher retries and idempotent consumers. A modernized system may initially cost more while old and new paths coexist.
Prove an incremental replacement with contract tests, event-schema compatibility, data reconciliation and rollback. Track an outcome such as reduced checkout failure or deployment time, not merely the percentage of code moved to microservices.
Scenario and rationale
An order monolith’s email step causes checkout failures when the mail provider is slow. First separate notification delivery through a durable queue and an idempotent worker. Keep order creation’s transactional boundary intact and publish events reliably, for example with an assessed outbox pattern.
Reject rewriting the entire application before isolating this failure. Reject independently writing the order and publishing an event without handling the dual-write gap. Reject moving all tables to DynamoDB without modeling joins, keys and business invariants.
Practice drill
Draw the existing transaction and the proposed event boundary. Enumerate failures before/after database commit and message acknowledgement. Define deduplication, retry/DLQ, schema versioning and reconciliation. Compare one container and one Lambda worker option using execution duration, concurrency, dependencies and total operating cost. Propose a staged rollout and rollback; no live deployment is claimed.
References
- Official Domain 4 task guide
- Strangler fig guidance
- Transactional outbox pattern
- Step Functions workflow types
- DynamoDB modeling
Return to Domain 4. The drill is proposed study work, not a claim of a completed deployment.