Your Project Architecture — Clean End-to-End Flow

1. Frontend (Angular + Web Components)

2. API Gateway (Apigee)

3. Backend Services (Spring Boot Microservices)

4. Deployment (GitOps + Spinnaker + Kubernetes)

5. Auth Flow (Okta)

6. High Availability + Scalability

Clean Diagram (Mental Model)

User Browser
    ↓
www.wecode.com (Angular + WebComponents)
    ↓
api.wecode.com (Apigee API Gateway)
    ↓
Apigee Auth (Okta) + Routing
    ↓
Azure Kubernetes Cluster
 ┌─────────────────────────────┐
 │ Students Service (Pods)     │
 │ Courses Service (Pods)      │
 │ Payments Service (Pods)     │
 └─────────────────────────────┘
    ↓
Databases / Other services

What to say in interview? (Clean summary)

“We have a micro-frontend architecture where an Angular app loads various Web Components, each calling its respective backend APIs via Apigee API Gateway. Apigee handles authentication (via Okta), security, and routing. Backend microservices are Spring Boot apps containerized via Jenkins and stored in a private Docker registry. Deployments are fully automated using a GitOps model where Spinnaker triggers Kubernetes deployments (Azure AKS) based on YAML manifest updates. Kubernetes ensures service discovery, load balancing, scaling, and self-healing.”

Why is this modern and scalable? (If interviewer asks)

Why you get errors like “Only X characters allowed” / “Max 10 MB data allowed”

These types of errors are API Gateway policy enforcement errors — not directly from your backend service.

Apigee sits in front of all your backend APIs and it applies policies like:

Policy Type Example
Request/Response Size Limits Max request payload size = 10MB
Header Size Limit Max header length = X characters
Query Param Validation Max param length, allowed patterns
Content Type Validation Only accept JSON, not XML
Rate Limits / Quotas Max 1000 requests per minute
Timeouts Request must finish in X seconds
Security Policies Disallow file uploads over X MB

If any of these policies fail, Apigee throws an error before even calling your backend service That’s why:

Real Example (Apigee policy config)

Here’s how an Apigee policy to limit payload might look:

<Step>
  <Name>VerifyPayloadSize</Name>
</Step>

<Javascript name="VerifyPayloadSize">
  <Properties>
    <Property name="maxPayloadSize">10485760</Property> <!-- 10 MB -->
  </Properties>
  <ResourceURL>jsc://verifyPayloadSize.js</ResourceURL>
</Javascript>

Or directly with a built-in policy:

<SpikeArrest name="limit-payload">
  <Properties>
    <Property name="maxRequestSize">10MB</Property>
  </Properties>
</SpikeArrest>

Clean interview explanation (if asked)

“Apigee can enforce API governance policies like payload size limits, header size limits, query param validation, and content type restrictions. When we see errors like ‘only 10 MB allowed’ or ‘param too long’, those are typically enforced by Apigee policies to protect backend services and ensure API stability.”

Bonus — Why these limits exist (good to mention in interview)

How to confirm it’s Apigee error (in real project)

Short answer: Yes, those limits are coming from Apigee, not from your backend Spring Boot service.

What is Axway? (In your project context)

In your project, Axway is used as an API Management / API Security Gateway, very similar to Apigee. It helps with:

Basically:

Axway is maintaining the “official allowed API catalog”. If an API is not registered/declared properly in Axway → it is considered unauthorized → you get 403 Forbidden.

Your GitOps repo → Axway folder → API Specs

That folder contains:

When you deploy a new backend service (say “Students API”) — If that API’s spec is not present or not registered correctly in the Axway repo, Axway blocks requests to it and returns 403 Forbidden (“This API is not allowed / not published / not authorized”)

Clean flow of what’s happening

Frontend Angular
      ↓
api.wecode.com (Apigee API Gateway)
      ↓
→ Apigee authenticates token (Okta)
→ Apigee checks routing

Apigee sends request to:
↓
Axway API Manager
→ Is this API spec registered and allowed? (From GitOps Axway folder)
   - Yes → forward to backend service
   - No  → 403 Forbidden (blocked)

↓
Backend Spring Boot Service (in Kubernetes)

Why are both Apigee AND Axway used?

In many enterprises (like yours), Apigee is used mainly as the external API Gateway (handling client traffic, security, token validation)

And Axway is used as a central API management / governance platform to:

Interview-ready explanation (if asked)

“In our project, Apigee handles external API Gateway tasks like authentication and routing, while Axway governs API specifications and ensures only registered, approved APIs are accessible. If a new backend API is deployed but not registered in Axway via our GitOps specs folder, Axway blocks the request and returns a 403 Forbidden error, ensuring API governance and security compliance.”

So to answer you clearly

Yes — the 403 Forbidden you mentioned (for new APIs) → It is because Axway is blocking that API due to missing or unregistered spec → You need to add the API spec in GitOps Axway folder to allow traffic

Axway is not specific to your project; it’s actually a well-known, enterprise-grade API management platform used by many organizations for managing, securing, and governing APIs.

So, Axway is a real product and is commonly used in industries that deal with complex API ecosystems, needing advanced control over their APIs, such as:

Key Features of Axway:

  1. API Gateway: Manages API traffic and secures it (similar to Apigee). It supports rate limiting, authentication, API routing, and more.
  2. API Management: Allows enterprises to define, register, and control which APIs are exposed (and which are not). Provides security policies, access control, versioning of APIs.
  3. Security: Enforces security policies like OAuth, rate limiting, throttling, and more. It also helps with monitoring and logging.
  4. API Analytics: Offers analytics to track usage patterns, error rates, and API performance metrics.
  5. API Lifecycle: It helps manage the entire lifecycle of an API (from design to deprecation).

Axway in General

Axway is widely used across many industries, not just yours. Some of the use cases for Axway could include:

Axway API Management Solutions Include:

Axway’s Role in Your Project

In your specific project, it seems that Axway is playing the role of API Governance. You are using it for managing and securing your APIs (defining which are allowed, handling access control, etc.). When you get errors like 403 Forbidden for new APIs, it’s because Axway hasn’t registered or authorized that API yet.

Short Explanation for Interview/Clarity:

“Axway is an API management and governance platform used for securing and managing APIs. It allows enterprises to define, monitor, and control which APIs are exposed to clients. In our case, Axway is used to ensure that only approved and registered APIs are accessible. When new APIs are deployed but not registered, Axway blocks them, leading to 403 errors.”

So, Axway is a product used for API management and is not something unique to your project. It’s widely used in the industry for complex API ecosystems.

Your Frontend Setup: Micro Frontends Using Web Components

You have:

Each sub-app is:

These sub-apps are Web Components — meaning:

How Main Frontend Loads These Web Components

1. Build and Host

Each micro frontend (web component) is built separately → produces JavaScript bundles (e.g., student-app.js).

These JS bundles are uploaded somewhere (S3 bucket, Azure blob storage, or static servers).

2. Main App Loads Dynamically

In the main Angular app:

Example:

<!-- Inside Main Angular App -->
<student-app></student-app>

Behind the scenes:

Summary of the Full Flow

Step What happens
1 Each web component is built separately and hosted somewhere
2 Main Angular app has a config mapping URL and web component name
3 When user navigates to a specific route, the main app loads the JS bundle
4 Browser registers the Web Component
5 Main app renders the custom element like a normal Angular component
6 Web component runs its own Angular code internally, independent of main app

Bonus: Why this Micro Frontend Architecture?

Small Interview-Ready Summary

“In our project, we use a micro frontend architecture where each web component is a separately developed and deployed application. The main Angular app dynamically loads these web components based on user navigation. It treats them like standard HTML elements, allowing independent deployment and scaling of different parts of the application.”

1. What is Docker?

Docker is a tool that packages your application (code + dependencies + environment) into a Docker Image. That image can run anywhere (on your laptop, server, cloud) — exactly the same way.

Why do we use Docker?

Because:

Example

Your Student Service (Spring Boot app) → You want to Dockerize it.

You write a Dockerfile:

FROM openjdk:17-jdk
COPY target/student-service.jar app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]

When you run docker build, it creates a Docker Image → e.g., student-service:v1.0

This image contains:

2. What is Artifactory?

Artifactory is like a storage or repository (just like Git stores code, Artifactory stores built artifacts). In your case, it stores Docker images and maybe JARs, NPM packages, etc.

You can think of it as:

“A private DockerHub / Maven Central for your company.”

Why do we use Artifactory?

Because:

Example Flow

Step What happens
1 You build Docker Image of Student Service on Jenkins
2 Jenkins pushes that image to Artifactory (your private Docker registry)
3 During deployment, Kubernetes pulls that image from Artifactory and deploys it

Your Project Flow — Docker + Artifactory

  1. Developer writes code (Spring Boot)
  2. Jenkins builds the code → creates Docker image → e.g., student-service:v1.2
  3. Jenkins pushes that image to Artifactory → artifactory.wecode.com
  4. You update .yaml file (GitOps repo) with new image tag → e.g., image: artifactory.wecode.com/student-service:v1.2
  5. Spinnaker sees the change and triggers deployment on Kubernetes
  6. Kubernetes pulls image from Artifactory → runs it in a pod

Quick 1-Line Definitions (For Interview)

Tool Simple Definition
Docker Packages application + dependencies into portable container images
Artifactory Private repository to store Docker images (and other artifacts) securely
Jenkins CI/CD tool to automate build, test, and deployment
Spinnaker Continuous delivery tool to automate deployments (works with K8s)

Your Interview-Ready Summary

“In our project, we use Docker to package backend services into images. Jenkins builds and pushes these images to our private Artifactory (Docker registry). Kubernetes then pulls the images from Artifactory and deploys them in pods, ensuring consistent environments across all stages.”

[End Users (Browser)]
↓
[Frontend (Angular)]
↓ REST API calls
[Apigee Gateway (API Proxy)]
↓ Routes to
[Kubernetes Cluster]
↓
[Spring Boot Backend (Deployed as Pod)]
↓
[PostgreSQL DB (K8s Service)]

1️⃣ What is Microservices Architecture? (Clear and Crisp)

Microservices Architecture is an approach where an application is built as a collection of small, independent services, each responsible for a specific business capability, and they communicate with each other over lightweight protocols (like REST APIs, messaging queues).

🔹 Core Characteristics

Principle Meaning
Independent deployability Each service is deployed separately
Single Responsibility Each service does one business function
Decentralized Data Each service owns its data, though in real world shared DBs exist too
Technology Diversity Services can use different languages / databases
Resilience Failure of one service doesn’t bring down the entire system
Elastic Scaling Services scale independently
DevOps Automation CI/CD pipelines, containerization, orchestration (e.g., K8s)

2️⃣ Your project — Full Microservices Architecture (Explained Clearly)

Here’s how YOUR project fits cleanly into a modern microservices architecture:

🖥️ Frontend (Client Layer)

🌐 API Gateway Layer

⚙️ Backend (Microservices Layer)

🛢️ Database Layer (Persistence)

📦 Infrastructure & DevOps Layer

📊 Documentation & Developer Experience

🗺️ Full Diagram (Textual View)

[Angular SPA] --> [Okta Auth] --> [Bearer Token]
         │
         ▼
  [Apigee API Gateway] --> [Axway (Policy Validator)]
         │
 ┌──────────────┬─────────────┐
 ▼              ▼             ▼
Payments Svc  Accounts Svc  Other Svc
 own DB       shared DB     own DB
 Oracle/Mongo Oracle/Mongo  Oracle/Mongo
         │              │
   Kafka / REST    Kafka / REST
         │              │
 ┌──────────────┴─────────────┐
 ▼                             ▼
 [Elastic Logs]           [GitOps (K8s Deployments)]
                               │
                       Docker Images (Artifactory)

✅ Why YOUR project is clearly Microservices Architecture

Microservices Characteristic Your Project
Independent services Payments, Accounts, etc
API Gateway Apigee
Decentralized data Separate + Shared DBs
Polyglot persistence Oracle + MongoDB
Lightweight comm REST + Kafka
Independent deployability Via Docker + K8s
Authentication Okta + Spring Security shared repo
DevOps automation CI/CD + GitOps + Kubernetes
Observability Elastic Logs
Documentation Swagger / OpenAPI

📝 How to explain in interview (summary answer)

“Yes, we follow a microservices-based architecture in our project. We have multiple Spring Boot-based services like Payments and Accounts, independently deployed and exposed behind Apigee API Gateway. Our frontend is an Angular SPA that integrates with Okta for authentication. Backend services communicate using REST APIs and Kafka for async processing. We use a combination of Oracle and MongoDB for persistence. Kubernetes on Azure OpenShift manages our deployments via GitOps pipelines. CI/CD builds Docker images and pushes to Artifactory. We have centralized logging using Elastic Stack and document all APIs using Swagger. We also enforce fine-grained API security using Spring Security with role-based access controls.”

📝 Advanced Microservices Interview Q\&A (Customised to Your Project)

Q1. What is microservices architecture and how is it applied in your project?

Answer: Microservices architecture breaks a large application into small, independently deployable services, each responsible for a specific business capability.

In our project, we have multiple Spring Boot-based microservices such as Payments, Accounts, etc., exposed as independent APIs (apidev.xyz.com/payments, etc.). These services are behind an Apigee API Gateway, and they communicate using REST APIs and Kafka (for asynchronous messaging). Each service is independently deployed via Kubernetes and CI/CD pipelines.

Q2. How do you manage authentication and authorization in your microservices?

Answer: Authentication is handled using Okta. Our Angular SPA redirects users to Okta for login, and once authenticated, we receive a Bearer token which is sent in all API requests.

At the API Gateway level (Apigee), this token is validated. For backend services, we have a shared Spring Security Auth repository (added via Maven dependency) which uses annotations like @RolesAllowed to enforce role-based access control on individual APIs. This ensures fine-grained authorization.

Q3. How does your project handle service-to-service communication?

Answer: We use both synchronous and asynchronous mechanisms:

Q4. Do your microservices share databases or have separate databases?

Answer: We follow a hybrid approach:

We use both Oracle (relational) and MongoDB (NoSQL) depending on the service’s requirement.

Q5. How do you ensure scalability and high availability of services?

Answer: We deploy all microservices on Kubernetes (Azure Red Hat OpenShift). We configure replicaCounts in GitOps repo to scale services horizontally by increasing pods. If load increases, we simply update the replica count, and Kubernetes deploys more pods. Apigee handles load balancing between them.

Q6. How does your CI/CD pipeline work for microservices deployment?

Answer: We use a GitOps-based CI/CD pipeline:

  1. Code changes trigger a build pipeline.
  2. A Docker image is built and pushed to Docker Artifactory.
  3. GitOps repo is updated with the new image tag.
  4. Kubernetes automatically pulls the new image and deploys it.

This ensures automated, consistent deployments.

Q7. How do you monitor and debug your microservices in production?

Answer: We use Elastic Stack (ELK) for centralized logging. All logs from different services and Kubernetes pods are forwarded to ElasticSearch for searching and analysis. We also check Azure OpenShift pod logs for real-time debugging.

Q8. How is API documentation managed in your project?

Answer: All backend APIs are documented using Swagger / OpenAPI specifications. This helps both internal and external developers to understand and consume the APIs easily.

Q9. How do you handle failures and retries in your microservices communication?

Answer:

Q10. How does your project ensure secure communication between microservices?

Answer:

Q11. How do you manage configuration across environments in microservices?

Answer: We use GitOps repositories to maintain Kubernetes YAML files per environment. Configurations like replica counts, Docker image tags, environment-specific variables are managed through these YAMLs. Secrets (like DB passwords) are managed using Kubernetes Secrets.

Q12. How does your project handle schema changes when services share a database?

Answer: We carefully coordinate schema changes by:

Whenever possible, we prefer separate databases to avoid this complexity.

Q13. What is the role of Axway in your architecture?

Answer: Axway acts as an API validation and policy enforcement layer. It validates incoming API requests, enforces policies, and returns meaningful errors if an API is not configured properly. This adds an extra layer of governance and robustness before requests reach backend services.

Q14. What challenges have you faced working in microservices architecture?

Answer: Some challenges include:

Q15. How do you ensure backward compatibility when updating services?

Answer: We follow API versioning and ensure that new changes are backward compatible. Old consumers can continue using v1 APIs while new features are added to v2 APIs. We test both old and new API versions thoroughly before deployment.

✅ How to use this?

→ Practice these answers in your own words but keep all the technical depth → Be ready to give real project examples (like I’ve shown) → Interviewers want both concept clarity + real-world experience = You’ll stand out

Excellent — here’s both: ① 5 super advanced microservices interview questions (with model answers based on your project) ② System Design questions (with hints to answer confidently)

① 5 Super Advanced Microservices Interview Q\&A (Architect Level)

Q16. How do you manage data consistency across microservices in your project?

Answer: We primarily follow eventual consistency. When multiple services need to update related data, we use Kafka events to propagate state changes asynchronously.

For example, when a payment is successful, Payments service publishes an event to Kafka. Accounts service consumes this event and updates account balances. We avoid distributed transactions to reduce coupling and instead design with idempotent operations and compensating transactions where necessary.

Q17. How does your project ensure observability in a distributed microservices architecture?

Answer: We ensure observability via:

We also use correlation IDs in logs to trace a request as it passes through multiple services.

Q18. How do you manage microservices versioning and backward compatibility in your project?

Answer: We expose versioned APIs (/v1/payments, /v2/payments) behind Apigee API Gateway.

When releasing a new version:

For internal service-to-service APIs, we ensure interface backward compatibility and test both old and new consumers before deployment.

Q19. How do you manage secrets and sensitive configurations across microservices?

Answer: We use Kubernetes Secrets to securely manage sensitive data (like DB passwords, API keys).

Secrets are:

We avoid hardcoding secrets or checking them into Git repositories.

Q20. How do you ensure fault tolerance and resilience of your microservices?

Answer: We follow multiple strategies:

② System Design Questions (With Approach Hints)

These may be asked to see if you can apply microservices concepts to design.

Q1. Design a payment processing system using microservices (similar to your Payments service)

Approach Hint:

Q2. How would you handle schema evolution if Accounts and Payments share a DB table?

Approach Hint:

Q3. Design a secure service-to-service communication mechanism.

Approach Hint:

Q4. Design a microservices logging and monitoring architecture.

Approach Hint:

Q5. Design a deployment strategy for rolling out a new version of Payments service without downtime.

Approach Hint:

✅ How to Prepare These

→ For each design Q, mention components, communication, security, scalability, resilience, monitoring, deployment (these 7 pillars — interviewers love that)

📝 Microservices Architecture (Your Project – Interview Summary)

🏛️ Core Architecture

Component Tech Stack / Tool
Frontend Angular SPA + Web Components
Auth Okta + OAuth2 (Frontend & Backend)
API Gateway Apigee (Auth + Routing)
Backend Services Spring Boot Microservices
Inter-service Communication REST APIs + Kafka
Databases Oracle + MongoDB (shared + separate)
Deployment Kubernetes + GitOps (ArgoCD or similar)
Observability ElasticSearch + Kibana (Logging), Azure OpenShift logs
CI/CD GitHub → Build → Docker Artifactory → GitOps deploy

🛠️ Key Patterns in Use

Feature Implementation
Authentication Okta tokens (Frontend) → validated by Apigee → backend
Authorization Spring Security (RolesAllowed)
API Versioning Managed in Apigee (/v1/payments, /v2/accounts)
Data Consistency Eventual Consistency (via Kafka)
Fault Tolerance Retry + Kafka DLQ + K8s Self-healing
Scalability K8s replicaCount (pods auto scale)
Logging & Monitoring Elastic + Correlation IDs + K8s logs
Secret Management Kubernetes Secrets
Deployment Strategy Rolling updates via GitOps + Docker tags

🎯 Killer Interview Phrases (use these confidently)

🚀 Advanced Concepts Ready to Mention

✅ Correlation IDs ✅ Kafka DLQ ✅ Kubernetes ReplicaSets & Self-healing ✅ Event-driven architecture ✅ Circuit breaker / Retry (Resilience4j — future ready) ✅ GitOps Deployment flow (Build → Docker Artifactory → GitOps repo → K8s) ✅ Hybrid DB strategy (Oracle + MongoDB)

📝 Microservices Architecture (Your Project – Interview Summary + Design Patterns)

🏛️ Core Architecture

Component Tech Stack / Tool
Frontend Angular SPA + Web Components
Auth Okta + OAuth2 (Frontend & Backend)
API Gateway Apigee (Auth + Routing + Rate-limiting)
Backend Services Spring Boot Microservices
Inter-service Communication REST APIs + Kafka (async)
Databases Oracle + MongoDB (shared + separate)
Deployment Kubernetes + GitOps (ArgoCD or similar)
Observability ElasticSearch + Kibana + Azure OpenShift logs
CI/CD GitHub → Build → Docker Artifactory → GitOps deploy

🛠️ Key Microservices Design Patterns (used / relevant in your project)

Pattern Where / How (Your Project Example)
API Gateway Apigee (handles auth, routing, rate limiting)
Circuit Breaker (Optional / Future) — Resilience4j for fault tolerance in REST/Kafka
Saga (Orchestration/Choreography) For distributed transactions (payments + accounts), Kafka-based async updates ensure eventual consistency
Event Sourcing Kafka (events persist history of state change, e.g., payment processed)
CQRS (Command Query Responsibility Segregation) Read-heavy APIs fetch data from cached or denormalized sources (MongoDB) while writes propagate via Kafka
Database per service Some services have dedicated DBs (Oracle / Mongo), some share DB (accounts + payments may share customer data)
Bulkhead Kubernetes pod/resource isolation prevents cascading failures
Retry + Timeout + Fallback REST clients and Kafka producers (using Retry templates / configs)
Service Discovery (optional) Static service discovery (via Apigee configs + Kubernetes DNS)
Externalized Configuration GitOps YAMLs (config maps, secrets) for environments

🎯 Killer Interview Phrases (use these confidently)

🚀 Advanced Concepts Ready to Mention

✅ Correlation IDs (for tracing) ✅ Kafka DLQ (Dead Letter Queue) ✅ Kubernetes ReplicaSets & Self-healing ✅ Event-driven architecture (Kafka-based) ✅ Circuit breaker / Retry / Timeout (Resilience4j ready) ✅ GitOps Flow (Build → Docker Artifactory → GitOps → K8s) ✅ Saga pattern (via Kafka for multi-service consistency) ✅ Hybrid DB (Oracle + MongoDB) ✅ Elastic stack for centralized logging

🗣️ Sample Interview Intro (Project Elevator Pitch)

“I work on a microservices-based architecture where our Angular SPA interacts with multiple Spring Boot services exposed via Apigee API Gateway. We leverage Okta for authentication (OAuth2), Kafka for event-driven communication, and a hybrid Oracle-MongoDB strategy for persistence. Our services follow patterns like Saga for distributed transactions, Database-per-service where applicable, and are deployed on Kubernetes using GitOps for seamless CI/CD. We ensure observability through Elastic logs and fault tolerance using retries and pod isolation.”

🎯 Advanced Microservices — Interview Q\&A (Tailored to Your Project)

1️⃣ What is Microservices Architecture? How is it applied in your project?

Microservices architecture breaks a large application into a collection of small, loosely coupled, independently deployable services. Each service has its own functionality, data, and deployability.

In my project: We have independent Spring Boot services like Payments, Accounts, etc., each exposed via Apigee API Gateway. Some have separate DBs (Oracle/MongoDB), and others share DBs depending on the domain requirement. They communicate via REST and Kafka.

2️⃣ How is authentication handled?

We use Okta (OAuth2) for user authentication. The token obtained post-login is passed as a Bearer token to the backend APIs.

Backend: Apigee validates tokens. APIs enforce roles via Spring Security using a shared Auth service (maven dependency). @RolesAllowed annotations protect endpoints without rewriting auth logic.

3️⃣ How does service-to-service communication work?

Primarily using REST APIs and Kafka (for async).

4️⃣ How do you ensure data consistency across services?

We follow Eventual Consistency via Kafka (Saga pattern).

Example: Payment → emits PaymentCompleted → Account service consumes event → updates account balance.

5️⃣ What patterns ensure reliability and fault tolerance?

✅ Retry + Timeout in REST and Kafka calls ✅ Circuit Breaker (we plan Resilience4j for flaky services) ✅ Bulkhead: K8s replica isolation prevents cascading failures ✅ ElasticSearch centralized logs + correlation IDs for tracing

6️⃣ How is CI/CD handled?

We follow GitOps for K8s deployments.

  1. Code pushed → triggers build → Docker image → Docker Artifactory
  2. GitOps repo updates tag → K8s cluster pulls new image
  3. Deploy via Helm / K8s manifests
  4. Configs managed in GitOps YAML (replicaCount, image tag)

7️⃣ Explain API Gateway usage in your project.

Apigee acts as our API Gateway.

✅ Authenticates Bearer tokens ✅ Routes requests to correct microservice (payments/accounts) ✅ Handles rate-limiting, logging, API versioning ✅ Provides developer portal + Swagger docs

8️⃣ Why did you use both Oracle and MongoDB?

Based on data modeling needs:

This follows Polyglot Persistence and Database-per-service pattern.

9️⃣ How do you monitor and debug microservices?

✅ ElasticSearch + Kibana → central logging ✅ Azure OpenShift → pod-level logs ✅ Correlation ID → track request flow across services ✅ Apigee Analytics → API usage + latency

🔟 What are the main challenges in microservices you faced?

🛠️ Extra Credit Qs (If you want to shine more)

Question Smart Answer (Your Project)
How do you version APIs? Using Apigee route configs (v1, v2 paths)
How do you roll back bad deployments? GitOps revert + redeploy (image tag rollback)
How do you secure inter-service comms? OAuth tokens + mTLS (if applicable) + Spring Security
How do you handle large payloads? Kafka compression + REST pagination
How do you test microservices? Unit, Integration + Postman/Swagger + Contract testing (future)