Scribd Logo
Upload

Welcome to Scribd!

  • 8 views

    W7D1 - Sprint3 - LoadBalancer & AWS - Presenting Project During Interview (17june)

    Uploaded by

    rahulbadhe630

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd

    W7D1 - Sprint3 - LoadBalancer & AWS - Presenting Project During Interview (17june)

    Uploaded by

    rahulbadhe630
    8 views13 pages

    Original Title

    W7D1 - Sprint3 - LoadBalancer & AWS - Presenting Project during Interview [17June]

    Copyright

    © © All Rights Reserved

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    8 views13 pages

    W7D1 - Sprint3 - LoadBalancer & AWS - Presenting Project During Interview (17june)

    Uploaded by

    rahulbadhe630

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    of 13

    Live Diagram:

    Sprint3:
    -------

    Sprint Planning

    All required would be put as user stroies in jira board.


    all clarity on requirement.
    Story pointing 1 2 3 5 8 13
    time "4 MAN DAYS".
    (Dev(unittesting) +
    QA(testcase + testing))
    /2
    2

    complexity - 1
    0.5, 1, 1.5, 2.
    risk - 0
    0.5, 1, 1.5, 2.

    Story points : 3

    Velocity: Total number of story points per sprint


    25 storypoint

    S1: 20
    S2: 25
    S3: 30

    (20+25+30)/3

    Average velocity

    Task Allocation:

    Tasks to be done in

    TODO section of sprint..

    TODO => INPROGRESS => DONE

    Approach 2:
    In begining of sprint, we finalize who should work on what tasks.
    Added as Assignee for the requirements.

    Sprint Starts:
    2 weeks

    - before you start your sprint, 80% requirements should be clear.


    - Once sprint start, dont change the scope

    - 4days of sprint 120% efforts.


    6 days have time..

    - Tasks:
    Server Dev
    UI Dev
    Devops
    Non java developer
    QA

    Open Sources
    1. Redis caching. 1 functional usecase. payment-validation.
    2. Logging (S.o.p)
    3. Sensitive data, db passwords..
    PROD
    cannot keep in property - Bitbucket
    AWS Secrets Manager

    2 Tasks:
    4. Async processing system
    ActiveMQ/RabbitMQ/Kafka - Message brokers.
    5. Business validation
    Blacklisting

    2 weeks of sprint:
    Week7.
    Week8 - off.
    Demos

    End of Internship 28th June


    ========================

    Microservice architecture..

    NonProd & PROD

    http://<PublicIP>:8081/v1/payments

    http
    default port is "80"
    https
    default port is "443"

    http://<PublicIP>/v1/payments
    Default it tries to connect to 80 port running on
    above IP.

    https://<PublicIP>/v1/payments
    Default it tries to connect to 443 port running on
    above IP.

    We cannot give below url to ecommerce for integration


    http://<PublicIP>:8081/v1/payments

    because both IP & port can change.

    Domain

    google.com
    facebook.com
    subdomain
    api.google.com

    api.google.com : <PublicIP>

    http://api.google.com:8081/v1/payments

    default port configuration

    http://api.google.com/v1/payments
    80

    https://api.google.com/v1/payments
    443

    which IP to map to the domain??

    api.google.com : ApplicationLoadBalancer IP/domain

    We will not expose our services to outer world.


    Rather expose via LoadBlancer.

    Microservice
    How Service1 talks to Service2??

    1. Approach1:
    Eureka Service Registery (Central component)

    2. Approach2:
    LoadBalancer & Target groups.

    3. Approch3: Build
    AWS ECS (Amazon Elastic Compute Cloud)

    1. Have public facing ALB for all incoming traffic.


    2. Enable WAF rules for all incoming traffic (ALB)
    3. Setup another ALB for invoking any internal service
    4. AutoScale Groups. we can setup target group

    Auto Scaling.
    When traffic grows, create new services.
    When traffics shrinks, then delete new services.

    ======

    Resume project walk through.

    Security:
    Spring Security
    HmacSHA256
    RSA
    aws secret manager
    Validation rules
    WAF

    robust : strong:
    microservice
    infra (EC2, RDS, Secretmanager)

    payment system
    Domain knowledge

    Ecommerce
    Domain knowledge
    Shopping cart.
    OrderManagement Service

    API integration with Trustly


    Full flow of Trustly
    Deposit request & response
    success/failure
    trustly-provider service
    JSON over RPC
    Security RSA
    RestAPI
    Network failure.
    null.
    for current launch, we are coding one time.. but looks like in future, we will
    implement more retry for network failure.
    Trustly Mock service.

    when service2 will not respond.


    Service is down.
    Service running on 80%CPU - timeout
    Service Unavailable..

    How many times to retry,


    frequency of retry..
    5mins, 10mins.. ???
    2 4 8 16

    Microservice architecture
    relate theory & practicals on project

    infra (EC2 (1core, & 2GB RAM), RDS, Secretmanager)


    basic commands
    mobaxterm
    scp
    ssh
    nohup heap memory should be allocated.
    tomcat
    backiup previous jars..

    Docker
    tail & grep & vi
    .pem file for connecting.

    Agile:
    Currently you are doing sprint by sprint development. Is it being deployed in LIVE
    systems?
    When is the plan to open to LIVE customers..

    Validation service
    - Some more rules needs to be developerd on validation.

    processing-service: 100 completed.


    Payment status management
    Notification

    Trustly provider
    - mock service
    - connect to test/non-prod trustly env & complete end-to-end testing.

    Reporting/Backoffice service

    =======

    QA bug fix:
    cut branch from integration
    fix code - complete dev testing
    Pull request to integration
    code review & merge
    deploy on qa env.
    give bug to qa in jira
    qa signsoff.

    UAT bug cycle


    cut branch from release branch
    code fix - dev test(Check on avaialble env)
    Pull request to release branch
    code review & merge
    deploy on UAT (release branch)

    PROD bug cycle - "Hotfix"


    cut branch from master/main
    code fix - dev test
    choose the env, closets to prod version (UATenv)
    Pull request to main branch
    code review & merge
    deploy on PROD

    Daily downmerge integration branch to feature branch..

    When a bug comes, identify which branch is deployed on that env. And cut a branch from that..
    and do the bug fixing..

    - Fraud customer:
    3rdParty - ComplyAdvantage
    not a blocker for GoLIVe.
    Currently in Trustly we are requetsing to enable these configuration.

    Design and development of Validation Framework


    - theory + practice
    - rules
    - names
    - all rules in separate classes
    - factory design pattern
    - when failure happens, throw exception.
    - if success runn till completion
    - as soon as 1st fialure happens, return response. dont run fully.

    Spring Security:
    error handling system
    Any failure in system, we identify it & throw custom exception.
    Custom Exception
    "Exception"
    consistent error response structure is sent.
    Global expection handler
    errorcode & errormessage
    http status code
    ResponseEntity
    Every service should have one sequence of errorcodes
    any error generated by that service, should use its given errorcode sequence.
    validation: 10xxx
    processing: 20xxx
    trustly-provider: 30xxx
    - If error is coming from upstreme server, then that errorcode should be return
    back as itself to invoker..
    eg, if trustly provider return 30xxx, then processing servier will return same 30xxx
    in response to validation service. And validation service will return same 30xxx to ecommerce
    system.
    - looking at error code, we can understand which part of system triggered the
    problem..

    field & business validations


    structure
    fields: email, phone,
    "paymentMethod": "APM",
    "providerId": "Trustly"

    duplicate
    payment attempt threshold
    backlist..

    design patterns
    factory dp
    builder dp

    modular systems
    all project standards.. packaging..
    dp..
    microservices..

    - Any word in resume can be questioned.. theory + practical.


    if you are not confident dont include..
    - whatever mentioned in project deccription.. same thing in one line explain in responsiblity.
    make it sspecific
    - Have resume - technology specific.

    For each of this, list down 5 points...


    Release these points together.

    secure
    Spring Security
    HmacSHA256 &
    RSA,

    Spring Security
    HmacSHA256
    Exception handling

    Ecoomerce
    (Filter)

    Microservice
    Validation service

    Validation service
    Validation frame
    errorcode
    resttemplate

    resttemplate
    trustly provider - 3rdpary

    List of topics:
    secure
    robust
    payment system
    e-commerce
    Did API integration
    Trustly
    Spring Boot
    microservices architecture,
    AWS.
    Agile
    Trustly PSP integration
    Design and development of Validation Framework,
    Spring Security
    HmacSHA256 &
    RSA,
    error handling system,
    field & business validations,
    Spring JDBC for DB,
    3rdParty Trustly APIs.
    Using design patterns
    Build Rest APIs
    strong debugging & problem solving skills.
    Redis Caching
    ActiveMQ

    You might also like