Meta .NET Developer Interview Questions & Answers

At a high level, my design thinking starts with understanding the user problem before choosing technology. The main challenge is balancing correctness, speed, security, cost, and simplicity without overbuilding. I organize the work into four steps: clarify and frame, explore trade-offs, design and validate, then build and iterate. The .NET architecture in the diagram is one example of applying those choices. I start simple, measure results, and add complexity only when the evidence supports it.

This question is asking how I make design decisions when there is no single perfect answer. I need to show that I understand the user problem before choosing technology. I should compare reasonable options, explain why one choice fits better, test risky assumptions, and improve the design after learning from real use. The diagram shows this as four connected stages: clarify and frame, explore and weigh trade-offs, design and validate, then build and iterate. The .NET architecture below those stages is a concrete example of how those decisions can become a working system.

1. Who are the main users, and what problem matters most to them?
2. What does success look like for this product or system?
3. Which matters most here: correctness, latency, availability, security, cost, or simplicity?
4. What scale and traffic pattern should I assume?
5. Are there privacy or compliance requirements I must protect?

I would start by saying, "Before choosing an architecture, I want to understand the user goal and the constraints." I define the scope, success measures, and important assumptions. I also identify risks early. This prevents me from solving the wrong problem or adding technology that does not help.

Next, I compare a few reasonable choices against the same goals. The diagram calls out consistency versus availability, latency versus throughput, simplicity versus flexibility, and cost versus performance. I prefer an MVP path first. For example, I would start with a modular monolith and split services only when there is a clear reason. The important part is explaining why the trade-off fits the current need.

Then I turn those choices into a high-level design and define the important data and API contracts. I validate risky areas with a spike or proof of concept before committing to a larger build. I also think about the threat model, which means asking how the system could be misused or attacked.

In the example architecture, clients send HTTPS requests through the Edge & Security layer. The API Gateway terminates HTTPS. Authentication checks identity. OpenID Connect can provide sign-in, while OAuth 2.1 can control delegated access. Authorization checks roles or policies. Validation checks input, and rate limiting controls excessive requests.

Validated requests reach the ASP.NET Core Web API and its Application Services. Commands handle writes, while Queries handle reads. The application can use the Primary Database, optional Read Replica, Distributed Cache, Object Storage, and External Services as shown.

Task-based asynchronous I/O lets .NET wait for I/O without holding a worker thread during that wait. Separate background work goes through the Message Broker to Background Workers using .NET BackgroundService. The Outbox / Inbox path supports reliable processing around transactional work. This keeps suitable background activity away from the main response path.

I would ship in small steps and measure what actually happens. Logging, metrics, tracing, and alerts provide that feedback. I revisit assumptions and refine the design as real data arrives. The main principle is simple: add caching, replicas, queues, resilience, or extra services only when they solve a measured problem. These tools can improve performance or reliability, but each one also adds cost and operational complexity.

At a high level, the goal is to keep unreliable or harmful news from dominating the social feed. The hard part is making trustworthy decisions without making feed delivery too slow. I would split the design into content analysis, background signal processing, feed ranking, and human review. Models, rules, verified sources, and user signals produce integrity scores. Ranking uses those signals to allow, downrank, or block content. The trade-off is better safety at the cost of more processing, storage, and moderation work.

The system must decide which news is healthy enough to show in a social feed. This is difficult because no single model, rule, report, or source can always make the right decision. We need several signals and a safe way to combine them. We also need feed ranking to react to those decisions without waiting for every slow background job. The diagram solves this by separating request protection, content analysis, background processing, storage, ranking safeguards, human review, and operational monitoring.

1. Should high-risk content be blocked immediately, or reviewed before removal?
2. How quickly must new integrity signals affect feed ranking?
3. Which disputed cases must always go to a human moderator?

I would start with how users enter the system. Mobile apps, web apps, and third-party clients send HTTPS requests through the Edge & API Gateway. This layer performs OAuth 2.0 token validation, authorization using scopes or RBAC, input validation, rate limiting, and DDoS protection.

The gateway forwards valid requests into the .NET microservices. The diagram shows ASP.NET Core services using the .NET 8 or .NET 10 generation with C# 12 or C# 14. The gateway also returns the JSON response to the client.

For new content, the Content Ingestion Service normalizes the post. It extracts text, entities, and media, then removes duplicates. The Feature & Signal Extraction Service builds linguistic features, source signals, engagement patterns, and graph signals.

The ML Inference Service produces a fake-news score, credibility score, and top reasons. The Policy & Decision Service then applies thresholds and risk bands. Its actions are allow, downrank, demote, or block. This publish decision becomes an input to feed generation.

I would keep slower signal work away from the main request path. The Message Queue or Event Bus, shown as Azure Service Bus or Kafka, carries events into Stream or Batch Processing. BackgroundServices and workers perform that processing. Aggregations & Indexing then prepares searchable and combined data using Elasticsearch or OpenSearch.

Verified external signals can enter this background path. The diagram shows fact-checking APIs, trusted news organizations, and government or public data feeds. These sources provide extra evidence rather than making the final decision by themselves.

The Data & Storage Layer separates different kinds of data. The Operational DB stores users, content, policies, and actions. The Feature Store or Cache, shown as Redis, keeps user, content, and model features. Object Storage keeps media, documents, and raw content.

The Model Registry & Artifacts store model versions. The Analytics Warehouse stores training data and reports. The Search Index stores content, entities, and signals. Background processing reads and writes these stores as needed.

For feed delivery, Candidate Generation finds possible items. Ranking with Integrity Signals uses credibility score, source trust, user feedback, diversity and freshness penalties, and safety rules. Healthy content can appear normally. Downranked content appears less. Blocked content is hidden before the Final Feed reaches users.

High-risk or disputed items can enter the Triage Queue. A moderator reviews the content and signals in the Moderator Console. The applied decision can update labels, policies, and model improvement data. Feedback and labels flow back into the system so later decisions can improve.

Metrics, logs, traces, alerts, dashboards, audit records, and privacy controls watch the whole design. The main trade-off is that stronger integrity checks improve safety, but they add processing cost, storage, operational work, and possible delay.

At a high level, I would give a clear count of the products or major launches I actually shipped. The main challenge is defining what counts as shipped and separating my ownership from shared team work. I would organize the answer around the total count, two or three strong examples, my ownership, and measurable outcomes. For each example, I would explain the problem, what I owned, what shipped, and the result. I would choose a few concrete launches instead of giving a long project list.

This question is asking for more than a number. The interviewer wants to understand what you actually delivered, how much of each product you owned, and what happened after launch. The difficult part is deciding what should count as shipped without making the number sound inflated. A strong answer starts with a clear total and then proves that total with two or three strong examples. For each example, explain the problem, your ownership, what reached users, and the outcome. Then close by connecting those examples to your overall delivery record and what you learned.

1. Would you like me to count only full products, or major feature launches too?
2. Should I focus on my most recent role or my full product career?
3. Would you prefer two or three detailed examples after the total count?

I would start with the number I can defend clearly. I would state how many products or major launches I shipped and the time span involved. I would also separate true 0-to-1 launches from major iterations. This gives the interviewer a simple starting point before I discuss individual examples.

Next, I would choose two or three strong Product or Initiative examples. For each one, I would explain four things: the problem, what I owned, what shipped, and the outcome. I would not give a long list of every project. A few concrete examples make the total count easier to trust and remember.

For each example, I would explain my exact role. That could include strategy and prioritization, requirements and scope, cross-functional execution, or launch readiness. If ownership was shared, I would say exactly what I owned. I would not claim the whole product when I only owned one part. This shows good judgment and makes the answer credible.

I would count a full product launch, a major feature launch, or a platform or infrastructure launch with real user or business impact. I would not count minor tickets or partial contributions as separate products. If the final number depends on my definition, I would define that clearly before giving the count.

For each example, I would add useful evidence such as the launch date, target users, team or partners, and my exact role. I would briefly explain the delivery story as discovery, prioritization, execution, launch, and iteration. Then I would describe the outcome using adoption or usage, revenue or growth, retention or engagement, efficiency or quality, or an important learning. I would close by repeating the total shipped count, highlighting the strongest two or three launches, being clear about ownership, and ending with impact and lessons learned.

At a high level, I would choose Spotify and focus on making discovery feel fresh without losing relevance. The main challenge is balancing personalization with enough novelty so recommendations do not become repetitive. I would explain the answer in three parts: identify the user problem, prioritize an Adaptive Discovery improvement, and test it with clear success metrics. Then I would learn from the experiment and roll out gradually. The key trade-off is relevance versus novelty.

The goal is to choose one favorite product, explain what already works well, find an important user problem, and propose an improvement that can be tested. I would pick Spotify. Its large content catalog, strong personalization, and cross-device experience are major strengths. The problem is that discovery can become repetitive. Users may keep seeing similar content and miss relevant new or niche music. I would organize the answer around the user problem, Adaptive Discovery, the success metrics, prioritization, experimentation, and the continuous improvement loop.

1. Should I focus mainly on active listeners who already use recommendations often?
2. Should success favor discovering new content, long-term satisfaction, or both?
3. Are there privacy limits on the listening signals I can use?

I would say my three favorite products are Spotify, Google Maps, and Notion. Spotify is strong at discovery and personalization. Google Maps is strong at navigation and local discovery. Notion is strong as a flexible knowledge and workspace product.

I would choose Spotify because the improvement opportunity is clear and measurable.

Spotify already has a large content catalog, strong personalization, and a good cross-device experience. The core problem is that discovery can become repetitive. New or niche content can become harder to surface.

The primary users are active listeners who want fresh music without excessive search. A secondary group is users whose recommendations already feel repetitive. Their job is simple: help me quickly discover something relevant but new.

My improvement would be Adaptive Discovery. It uses listening history, explicit likes and dislikes, skips, saves, context, and diversity signals.

The goal is to keep recommendations personalized while deliberately introducing relevant new and niche content. This directly addresses repetitive discovery without replacing the existing recommendation experience.

I would measure plays, skips, likes, saves, searches, and playlist adds. The primary metric is discovery engagement with newly surfaced content.

I would also use guardrails. These include skips or hides, retention, satisfaction, diversity, and privacy. I would prioritize Adaptive Discovery first because it has high user reach, directly addresses repetitive discovery, creates measurable behavior change, and can be tested incrementally.

I would A/B test current recommendations against Adaptive Discovery. I would segment the results by listener behavior and compare discovery engagement with the guardrail metrics.

Then I would analyze the experiment results. I would identify winning and harmed segments and adjust ranking or diversity controls. I would roll out gradually only when the primary metric and guardrail metrics are healthy.

The improvement loop continues after rollout. We collect signals, analyze the user problem, prioritize a hypothesis, run an A/B test, measure primary and guardrail metrics, learn what worked, and iterate or roll out. The main trade-offs are relevance versus novelty, personalization versus privacy, short-term engagement versus long-term satisfaction, discovery quality versus catalog diversity, and experiment speed versus user-risk guardrails.

At a high level, I had to choose which projects and features deserved limited engineering time. The main challenge was balancing user impact, business value, effort, risk, and stakeholder needs. I organized the work into intake, prioritization, and execution. We normalized requests, used RICE plus strategic fit, reviewed capacity and tradeoffs, and committed to one shared roadmap. We then measured results and fed those lessons into the next cycle. The trade-off was choosing fewer high-value items instead of trying to satisfy every request.

In one planning cycle, I had more valuable projects and feature requests than the team could deliver. The goal was to choose the work that created the most user and business value. The difficult part was comparing very different requests fairly while considering engineering effort, risk, and limited capacity. I used one repeatable process from the diagram. We collected and normalized requests, scored them, reviewed strategic fit, aligned stakeholders around one roadmap, executed the selected work, measured results, and used those lessons in the next cycle.

1. Which user or business goals matter most for this planning cycle?
2. How fixed is engineering capacity for the period?
3. Are any risk or compliance items mandatory?
4. How often can the roadmap be reviewed and changed?

I would say, "I first made sure every request entered the same process." The inputs came from User Insights, Business Goals, Pain Points, Ideas & Requests, and Data & Metrics. We used the Intake Portal / API to collect context, problems, and goals.

Then we de-duplicated similar ideas, tagged and classified them, and performed Initial Validation. Valid items entered one Backlog. This gave everyone the same starting point instead of letting the loudest request win.

Next, I used RICE scoring. RICE means Reach, Impact, Confidence, and Effort. Reach asks how many people are affected. Impact asks how much value the work creates. Confidence shows how certain we are. Effort represents how much work the team expects.

I combined that score with Strategic Fit. The diagram checks Alignment to OKRs, Risk / Compliance, User Experience, Engineering Capacity, and Monetization Potential. The score guided the discussion, but it did not replace judgment.

After scoring, we moved into Capacity Planning. We checked team bandwidth and dependencies before deciding what could realistically fit.

During Stakeholder Review, we discussed the tradeoffs and approvals openly. Then we committed to a Prioritized Roadmap using Now / Next / Later. We also communicated the roadmap and its rationale so stakeholders understood both the decisions and the reasons behind them.

The selected work moved through Plan & Spec, Build, Test & Validate, Launch, Measure, and Learn. The supporting layer included the Data Warehouse, Analytics, Feature Flags, A/B Testing, and Monitoring & Alerts.

Those tools helped us measure results and test assumptions. The learning then fed back into the next prioritization cycle. In the example shown, we chose a performance improvement with high reach and impact and lower effort over a new feature. That decision increased retention by 15% and freed capacity for future features.

The main tradeoffs were impact versus effort, short-term versus long-term value, certainty versus speed, user value versus business value, technical debt versus features, and risk versus opportunity. My goal was not to maximize one score. It was to make a transparent decision that the team could execute and stakeholders could understand.

At a high level, I used data to move a performance debate from opinion to evidence. Product pages were slow, but a stakeholder worried Redis would add cost and complexity. I organized the discussion around three steps: measure the current SQL path, run a bounded Redis proof of concept, and compare the results. The test showed lower latency, lower database load, and higher request capacity. Leadership approved a phased rollout, while SQL Server remained the system of record.

The question asks for a real example where measured facts helped change someone’s decision. In this case, product pages were slow and SQL Server was under heavier load during busy periods. A stakeholder was not convinced Redis was worth adding because it would increase cost and complexity. Instead of debating opinions, I collected production evidence, ran a small proof of concept, and compared both paths. I then presented a limited rollout plan based on the measured results. The story follows the diagram from the original concern, through evidence and testing, to the leadership decision and final outcome.

1. Should I focus more on how I collected the evidence or how I influenced the stakeholder?
2. Do you want me to explain the Redis proof of concept in technical detail?
3. Should I also explain the phased rollout and the measured outcome?

I would start by saying that product page loads were slow and database load increased at peak times. The stakeholder was concerned that adding Redis would create more complexity and cost. They also believed the existing SQL path might already be good enough. I wanted to prove whether caching would help before asking the team to make a larger change.

I collected 30 days of production telemetry and analyzed the current behavior. The diagram shows application logs, APM traces, database metrics, and user analytics as the evidence sources. The findings showed frequent product lookups hitting the database. Page-load latency increased during peak periods, database CPU and query load spiked, and request capacity dropped as load increased.

This gave me a baseline, which simply means the measured behavior before the change.

Next, I built a small proof of concept using Redis only for hot product data. I compared the SQL path with the Redis cache path. The cache path produced lower page-load latency, lower database load, and higher request capacity. The error rate stayed similar in the comparison.

The important point was that I did not ask the stakeholder to trust a theory. I showed a direct measurement from a limited test.

I proposed using Redis as a distributed cache for read-heavy, hot product data. SQL Server would remain the system of record, meaning it still held the official data. The plan also included a gradual rollout, monitoring, and a rollback option.

Leadership approved the phased rollout because the proof of concept directly addressed the stakeholder’s concerns about latency and database load.

In the rollout architecture, web, mobile, and partner clients send requests through the API Gateway or Reverse Proxy to the ASP.NET Core Web API. The application uses Redis for hot product reads and keeps SQL Server as the system of record for official data and write commands. When the cache does not provide the needed value, the SQL Server read path remains available.

OpenTelemetry traces, structured logging, metrics, dashboards, and alerts are used to watch the rollout. After release, the team observed lower user-perceived latency, lower SQL load during peak periods, and higher request capacity. The stakeholder aligned with the decision because it was based on objective measurements and a bounded proof of concept, not opinion.

At a high level, the problem was a gap between what stakeholders expected and what I understood. The main challenge was getting everyone aligned on scope, timeline, and data needs. I handled it in three parts: listen and clarify, adjust how I communicated, then validate the solution together. I used one-on-one talks, simple diagrams, prototypes, regular updates, and feedback. The trade-off was spending more time early, but that reduced later changes and improved trust.

The situation was difficult because different stakeholders had different expectations about scope, timeline, and data details. My first job was not to defend my technical approach. I needed to understand where our views were different. The diagram shows a five-stage journey. I first listened and mapped the gaps. Then I aligned goals and definitions. After that, I changed how I explained the solution, validated it with stakeholders, and used their feedback before delivery.

1. Would you like me to focus more on the communication problem or the technical solution?
2. Should I explain how I handled disagreement between several stakeholders?
3. Would you like me to describe how I measured whether communication improved?

I would start by saying, "The main problem was that we were using the same words but expecting different outcomes." Stakeholders had conflicting ideas about scope, timeline, and data details. Instead of assuming I understood them, I listened actively and asked open-ended questions. I mapped the gaps between their goals and my understanding. This gave me a clear picture of where communication had broken down.

Next, I would explain how I created a shared understanding. I held one-on-one conversations with key stakeholders. We defined goals, constraints, dependencies, and items outside the agreed scope. I also created a shared glossary and common data definitions. Finally, we agreed on success measures and milestones. This turned several different expectations into one clearer set of priorities.

Then I changed how I communicated. I stopped relying only on technical explanations. I used simple diagrams, examples, and a small prototype to make ideas easier to understand. I shared regular updates and demos instead of waiting until the end. I captured feedback and adjusted the plan. This helped stakeholders understand the approach and provide more consistent, useful feedback.

Once we had agreement, I built the prototype or agreed solution around the aligned requirements. I reviewed it with stakeholders before treating it as finished. We checked it against the agreed success criteria. When feedback showed a gap, I made improvements before delivery. This reduced the chance of discovering major misunderstandings late in the work.

The result was better alignment and stronger confidence in the direction. There were fewer changes after delivery, and decisions became faster. The process also improved collaboration because stakeholders could see progress and give feedback early. The main lesson was that clear communication is not simply sending more updates. It means listening, making ideas visible, agreeing on definitions, validating early, and changing the message when people are not understanding it.

At a high level, I would give a balanced view of what my manager has actually observed. The main challenge is showing real strengths without sounding self-promotional, while also naming a believable improvement area. I would organize the answer around manager feedback, supporting evidence, one constructive criticism, and the actions I am taking. My strengths are ownership, quality, problem solving, teamwork, and adaptability. My improvement area is delegating earlier and raising risks sooner while still maintaining strong delivery.

This question asks you to explain how your manager would describe your work and where they would want you to improve. The difficult part is sounding confident without pretending you have no weaknesses. A strong answer needs real evidence behind the strengths and one honest improvement area. The diagram organizes this as a simple growth flow. Manager Perspective and Evidence Behind the Feedback lead to a Balanced Manager Perspective. Then you explain how you respond, which actions you take, what results you see, and how you ask for feedback again.

1. Would you like one main strength and one improvement area, or a broader view?
2. Should I focus on feedback from my current manager or include recent project feedback?
3. Would you like a specific example showing how I acted on the criticism?

I would start with feedback my manager has actually given me. The Manager Perspective comes from regular 1:1 feedback, code-review feedback, project-delivery observations, and team collaboration. This keeps the answer grounded in real work instead of vague claims.

The Evidence Behind the Feedback makes those claims believable. I can point to reliable and maintainable work, problems I owned through completion, good collaboration, and times I adapted after feedback. That evidence supports the Balanced Manager Perspective.

I would say my manager sees strong ownership and follow-through in my work. They would also say I deliver high-quality, maintainable work, solve problems proactively, support teammates, and learn quickly.

Then I would give one real constructive criticism. My main improvement area is to delegate earlier and communicate risks sooner. I can sometimes take on too much myself or go too deep into details. I am working to surface risks and ask for help earlier.

I would show that I do more than simply accept the criticism. The flow is: Listen without defensiveness, Clarify the example, Choose one concrete behavior, Practice it deliberately, and Ask for follow-up feedback.

This matters because the interviewer wants evidence of growth. Feedback should lead to a visible change in behavior.

My Improvement Actions are practical. I delegate ownership sooner, time-box deep dives, raise blockers earlier, and share concise status updates. These actions directly address the criticism instead of hiding it behind a vague promise to improve.

The Constructive Criticism → Action → Evidence flow gives a concrete example. If I take on too much, I delegate earlier, check progress without taking the work back, and help the team gain more ownership.

The Result and Growth section shows the expected outcome. The results are better team leverage, earlier visibility of risks, faster decisions, and continued high-quality delivery.

I would finish with the Follow-up Feedback Loop. Manager feedback leads to behavior change, then I observe the outcome and ask for feedback again. This shows self-awareness and continued growth. The main balance is keeping strong ownership while creating more space for others to own work too.

At a high level, I would tell one specific story that shows what happened, what I owned, what I did, what changed, and what I learned. The main challenge is showing my personal contribution without taking credit for the whole team. I would organize the answer as Situation, Ownership, Actions, Impact, and Learning. I would make the result concrete and use a metric only when I can support it. The trade-off is giving enough detail to prove my contribution without making the story too long.

This question asks me to choose one achievement that genuinely matters to me and explain why I am proud of it. The difficult part is not simply describing a successful project. I need to show what I personally owned, what actions I took, what result followed, and what I learned. I also need to give fair credit to other people. The diagram gives a clear five-step path: Situation, Ownership, Actions, Impact, and Learning. That structure keeps the answer focused and easy to follow.

1. Would you prefer a recent work example, or can I use another professional example?
2. Would you like me to focus more on technical contribution, leadership, or business impact?

I would start by saying, "I will briefly explain the challenge, the context, and why it mattered." The Situation gives the interviewer enough background to understand the story. I would describe the problem and why solving it was important. I would keep this part short because the main value comes from what I personally did next.

Next, I would make my Ownership very clear. I would explain what I personally owned, the goal I was accountable for, and which decisions were mine. This matters because a successful team result does not automatically show my contribution. I would also avoid claiming work that belonged to other people. Clear Ownership gives the interviewer a fair way to judge my Actions.

Then I would explain the key decisions and Actions I personally took. I would include important collaboration and explain how I handled obstacles. I would focus on the few actions that had the greatest effect instead of listing every task. This part should show how I thought, how I made decisions, and how I moved the work forward.

After the Actions, I would explain the concrete Impact and why it mattered. If my real story includes a reliable metric, I would use it. If it does not, I would describe the result clearly without inventing a number. The Impact should connect directly to my Actions. That helps the interviewer understand what changed because of my work.

I would finish with the Learning from the experience. I would explain how it changed my approach and what I would repeat or improve next time. This shows growth instead of only celebrating success. The main trade-off is detail versus clarity. I need enough detail to prove Ownership and Impact, but not so much that the main story becomes difficult to follow.

At a high level, my bold decision was to replace a failing legacy .NET monolith in stages instead of continuing to patch it. The main challenge was improving reliability without risking one large cutover. I organized the work around the protected request path, background processing, and staged migration. We used small .NET services, durable messaging, observability, and controlled rollout steps. I accepted more operational complexity because the staged approach reduced blast radius and led to safer releases, better reliability, faster recovery, and stronger team ownership.

The difficult decision was to replace a legacy .NET monolith that was slowing releases and increasing operational risk. The hard part was not simply choosing newer technology. We had to change an important production platform without creating a larger failure. I chose a staged migration because it gave us smaller steps, validation points, and clear rollback options. The diagram organizes the solution around a protected request path, background processing, strong monitoring, and a four-step migration from the legacy system to smaller .NET services.

1. How much production risk can the team accept during each migration step?
2. Which business domain should move first?
3. How long can the old and new paths run together during validation?

I would start by saying the status quo had become the bigger risk. The legacy platform was slowing delivery and increasing reliability concerns. I chose staged replacement instead of a big-bang rewrite because it limited the blast radius. The main risks were cutover instability, data consistency, integration gaps, team ramp-up, operational complexity, and schedule pressure.

Mobile, Web, and Internal Systems send HTTPS requests into Edge & Security. The API Gateway uses YARP. Authentication uses OIDC through Auth0 or Entra ID. Authorization checks scopes and roles. Validation and rate limiting stop invalid or excessive requests before they reach the services.

Valid requests are forwarded to the .NET Services. The platform starts from .NET 8 LTS with C# 12 and has a planned path to .NET 10 LTS with C# 14. The Operations Service uses ASP.NET Core Minimal API, EF Core, and MediatR. The Scheduling Service uses ASP.NET Core Minimal API and Hangfire. The Notification Service also uses ASP.NET Core Minimal API. Responses return as JSON through the protected edge path.

The Operations Service reads and writes PostgreSQL Primary. The design also includes a PostgreSQL Read Replica for read scaling. Redis is a cache, not the main database. Blob Storage holds files such as avatars.

The services run as replicas in Kubernetes across multiple availability zones. The hosting layer also shows background workers, Kestrel over HTTPS, health checks and probes, and configuration and secrets from Azure Key Vault.

For work that should not block the main response, services publish events or jobs to RabbitMQ. BackgroundService consumers and scheduled .NET Worker jobs process that work. The messaging path includes retry and dead-letter handling. Background processing can also call SendGrid, Twilio, and the payment provider.

The migration has four steps: Strangler Fig, Dual Write and Validation, Read Cutover by Domain, and Decommission Legacy. CI/CD moves code through build, xUnit tests, SAST and DAST security scans, and deployment with Argo CD.

Seq collects logs, Prometheus collects metrics, OpenTelemetry provides traces, and Grafana provides dashboards. These tools help the team detect problems during each migration step.

The trade-off was more upfront complexity and operational work. We accepted that because staged rollout, smaller deployable units, idempotent handlers, backpressure and retries, security controls, and observability reduced migration risk. The outcome was improved platform reliability, faster and safer releases, lower incident-recovery time, and greater team ownership.