Spring Boot Microservices

Compare a modular monolith and microservices for a banking scenario in terms of deployment autonomy, data ownership, latency, partial failure, and operational cost.

Map customer management, account management, money transfer, and notification requirements to business capabilities.

Propose bounded contexts and justify which capabilities should become separately deployable services.

Assign exclusive data ownership to each proposed service and identify prohibited cross-service database access.

Draw a container-level architecture diagram showing users, services, data stores, communication paths, and external dependencies.

Define REST resources, HTTP operations, and status codes for customer and account management.

Specify request-validation rules and a consistent machine-readable API error format.

Generate and inspect an OpenAPI description for an existing Spring Boot account service.

Apply a backward-compatible change to an existing REST API contract.

Represent monetary amounts and currencies without floating-point rounding errors.

Model accounts and immutable debit-and-credit ledger entries while enforcing balanced postings.

Write a unit test for a money-transfer rule such as insufficient funds or incompatible currencies.

Create a versioned relational database migration for the account service.

Persist and query account and ledger data with Spring Data JPA while preserving aggregate boundaries.

Use one local ACID transaction to record a balanced transfer posting and update the affected account balances atomically.

Prevent lost balance updates by applying optimistic locking and handling version conflicts.

Select synchronous or asynchronous communication for a banking interaction based on response needs, coupling, and failure tolerance.

Implement a synchronous service-to-service request with a Spring HTTP client configured with explicit connection and response timeouts.

Design an idempotency-key contract for transfer requests and determine which failed requests can be retried without duplicate effects.

Route external requests to the appropriate banking service through an API gateway while keeping business logic out of the gateway.

Define a minimal integration event containing only the information another service requires.

Predict the effects of duplicate and out-of-order deliveries in an at-least-once messaging system.

Design a transactional outbox write-and-relay flow that avoids losing an event after a successful database commit.

Implement an idempotent event consumer that records processed event identifiers and ignores duplicate deliveries.

Classify the consistency guarantees of account balances, transfer status, and notifications.

Model an external-bank transfer as a saga, using compensating ledger entries rather than deleting financial history.

Apply an additive event-schema change without breaking an existing consumer.

Package a Spring Boot service as a container image using a reproducible build.

Run the banking services, databases, and messaging infrastructure together with Docker Compose.

Trace how a downstream failure can cascade through synchronous service calls.

Configure a circuit breaker around a failing non-transactional downstream dependency.

Use correlation identifiers and structured logs to follow one request across services.

Expose and distinguish liveness, readiness, and dependency health information with Spring Boot Actuator.

Diagnose a provided performance incident using latency, traffic, error, and saturation metrics together with a distributed trace.

Create a basic threat model for the banking system's external and service-to-service interfaces.

Explain the roles of OAuth 2.0, OpenID Connect, an authorization server, a client, and a resource server.

Configure a Spring Boot resource server to validate signed JWT access tokens.

Enforce role-based and account-ownership authorization on an account endpoint.

Produce a deployment security map that identifies secret-injection points and the connections requiring TLS.

Write a Spring Boot integration test against a disposable database using Testcontainers.

Use a consumer-driven contract test to detect a breaking provider change.

Evaluate the completed banking architecture for coupling, data ownership, consistency, security, failure handling, and operational complexity.