Odyssey Banking Microservices - Customer Profile and Registration

 

CHALLENGE OBJECTIVES

• Build the following microservices:

  • Customer Registration

  • Customer Profile

 

TECHNOLOGY STACK

• Java 11

• Spring 5.2.8

• Spring Boot 2.3.3

• Spring Security 5.3.5

• Spring GCP Cloud

• Istio (Discovery Service)

• APIGEE

• Log4j/Slf4j

• JSON (gzipped)

• REST

• Microservices

• Docker

• Kubernetes

• Open Api Spec 3.0

• SMTP

• MySQL 8.0

• JPA

• JUnit

 

REQUIREMENTS

The following common and generic requirements must all be followed:

• Implement the mentioned microservices below

• Follow the same structure and practices that we have implemented in the existing microservices, make sure you set up the same code style check and format commands like the existing ones

• All Data being Ingress or Egress from Spring Boot Application needs to be GZIPPED (see https://www.javainuse.com/spring/boot-zip for an example)

• Each of the microservices need to be buildable and deployable on its own, i.e. there should be no direct build dependency between any of them so we can have them in separate repos, and it must be possible to deploy them to different servers.

• Licenses to be followed in development:

  • Apache License 2.0

  • MIT License

  • Common Development and Distribution License

  • Eclipse Public License version 2.0

• Service should follow Spring Slueth Tracking (check the Server Side Request Tracking document shared in the forum)

• Implement logging properly for each service

  • Please follow the requirements in the Server Side Logging document shared in the forum

  • You must use Aspect Oriented Programming (AOP) for Trace Logging

• Exception handling should be implemented as described in the Service Exceptions Coding Convention document shared in the forum

• Service Registration and Service Discovery must be implemented (this is already done via Istio in the existing code, so you can just follow the same approach)

• Data traversal between the logical layers in microservice architecture should follow the scope bounding rules for application entities and domain entities, separation of concerns needs to be adhered to strictly:
  

• Other guidelines mentioned in the Guiding Principles document shared in the forum must be followed

• Service configurations must be done in key=value format so that it’s compatible with Kubernetes’s ConfigMap, and should support environment variable based configuration as well. Sensitive configurations will be put in Secrets instead.

• Reusability as much as possible. Please build common components in order to delegate basic activities like Encryption, decryption, masking, hashing etc. These components can be packaged into its own common components archives, reusable by all the microservices being developed. Please add common code to the existing cyn-common package.

• MySQL will NOT run inside Kubernetes, it’ll be MySQL SaaS in production but each microservice will have its own / separate schema.

• Service to service trust establishment mechanism must be implemented in the same way as the provided microservices.

• Please note we consider the requirements and client guidelines mentioned above to be major requirements.

 

Customer Profile Microservice

• This service is responsible for customer registration

• Please use com.cyn.ccds.customer.profile as root package name for this service

• Please check CYN-CustomerProfileService-250920-1616.pdf for the service details:

• Please check CYN-CustomerProfileServiceAPI-250920-1616.pdf for the API signature

• Proper configuration & logging should be implemented

• Provide a docker file for this microservice so we can build it into a docker image

• Junit tests are required for the service methods

 

Customer Registration Microservice

• This service is responsible for validation or retrieving customer profiles

• Please use com.cyn.ccds.customer.registration as root package name for this service

• Please check CYN-CustomerRegistrationService-250920-1614.pdf for the service details:

  • This service has dependencies on the following:

    • OTP Service

    • Customer Profile Service: used to match customer profile information

    • Authentication Service: ignore this dependency, the temp user should be generated by this service itself

    • Event Subscription Service: ignore this dependency in this challenge

  • Common Components Dependency:

    • The spec asks us to create multiple jars, but for now we can have them all in the cyn-commons library

• Please check CYN-CustomerRegistrationService-API-250920-1615.pdf for the API signature, here are a few things to note though:

  • /record should include two additional request parameters: email, phone number (including country code). It will verify if the provided info matches any customer profile (by using the Customer Porfile Service) and if yes, it will use OTP service to send OTP to the user, a temp registration UUID is also returned as part of the success response.

  • /evaluate should include an additional UUID field which is the one returned by the /record endpoint. The consumer of this endpoint should send the UUID, the OTP and channel identifier to this API which in term calls the OTP server to validate the OTP. If passed this endpoint will generate a temp user (both user id and password) and use the OTP service to send that to the user.

  • Ignore the /notify endpoint for now, i.e. there’s no need to implement it.

  • The two endpoints used to establish service to service trust must be implemented as we did in the existing services

• Please check CYN-CustomerRegistrationService-DataModel-250920-1615.pdf for the data model details and CYN-Customer-registration-flow.pdf for the registration flow.

• Proper configuration & logging should be implemented

• Provide a docker file for this microservice so we can build it into a docker image

• Junit tests are required for the service methods

Final Submission Guidelines

FINAL DELIVERABLES

• Full code that covers all the requirements.

• A detailed README file including information on how to configure, run, and verify your application.

• Maven script(s) that at least cover the following:

  • Run the services locally

  • Build each project into separate packages that can be deployed independently

  • Build each project into separate docker images

  • Run unit tests

  • Generate a sitemap for the project using Maven Site Plugin (mvn site)

• Postman collection file to properly test the API (covering positive and negative cases).