The startup intends to migrate its monolithic application to a microservices architecture to improve scalability, availability, and maintainability. Key objectives for the new architecture include service discovery, autoscaling of microservices, database design, load balancing, and avoiding downtime. The proposed architecture uses Kubernetes for container orchestration, includes an API gateway and load balancers for traffic routing, allows each microservice to have its own database, and implements fault tolerance techniques like retries and caching. The architecture would be deployed on AWS for its managed services.

1. Architecture
Migration
Ramakrishnan Seshagiri

2. Problem Statement
> A Start-up has
- A monolithic application
- Traditional 3-tier architecture (web server, JBoss, MySQL)
- Intends to migrate to an architecture that can handle future needs
> Futuristic Architecture needs
- Highly-scalable, highly-available, highly-performing
- Secure, efficient and elastic
- Easy to maintain

3. Customer's Specific Objectives
• Service Discovery
• Granularity of a microservice
• Autoscaling of microservices
• DB design (1 DB instance per microservice or 1 common DB instance)
• Data consistency across Microservices
• Loadbalancer configuration for distributing load
• Logging
• Avoiding Downtime
• Use of managed services to manage the microservices

4. Scalability & High-availability
> Network & Infrastructure load
- Load balancer for web servers to handle exponential growth in web traffic
- Cluster of web servers are run to ensure high-availability
- Based on rate limits or CPU/RAM usage limits, new containers will be
automatically spawned via Kubernetes
> Application load
- Incoming traffic is routed through an API gateway,
- Kubernetes Ingress & Application Load balancer (Layer 7) are used to
manage very high spurts

5. Modularity & Communication
> System is reduced to a number of much smaller pieces of
independent business logic (microservice)
> Each microservice will have its independent data persistence capability
- Depending on the service, the database could be RDBMS or NoSQL
> Each service can communicate with several or every other service
- IPC mechanism and data exchange mechanism for each communication
will be driven by the specific need (REST, XML/JSON or pub-sub with
queues)
> Server-side services discovery pattern using Kubernetes DNS

6. Fault Tolerance
> Service Failures
- Limit the number of waiting requests per service instance
- If number of failed requests breach threshold, mark the instance as "unresponsive" for a
specified period of time
- For non-transactional / information requests, cached data could be provided as a response
> Data Consistency Issues
- Services that deal with non-transactional information are recommended to have NoSQL
databases (scalable & flexible for different structured/unstructured formats of data)
- As much as possible, transaction logic should be contained within least number of services
(preferably 1) to prevent data inconsistency

7. Architecture
Web
Server
Web
Server
Web
Server
Clients
API
Gateway
Layer 7
LB
K8s
Ingress
S1
S4
S3
S2
S5
PrometheusLogstash

8. Architecture on AWS
Clients