Meta Python Developer Interview Questions & Answers

At a high level, this system accepts user prompts and returns safe streaming LLM answers. The main challenge is keeping responses fast while traffic, context size, safety rules, and model needs change. I would explain the design in three parts: the request path, the cache and model path, and the background event path. The LLM Orchestrator controls context building and model routing. The queue protects GPU Model Serving during traffic spikes. The main trade-off is lower latency and cost versus fresher context and more model work.

The goal is to accept a user prompt and return a safe answer as a stream. Streaming means the user sees parts of the answer before generation finishes. The difficult part is that the requirements may change. Traffic may grow, prompts may become larger, safety rules may become stricter, and some requests may need more context. I would keep the same main architecture and adjust the cache, queue, routing policy, and service capacity as those needs change.

1. Which user flows and system capabilities are required for the first version?
2. What traffic, data volume, latency, and availability targets should I design for?
3. Which consistency, security, geographic, and cost constraints matter most?

I would first explain which requirements affect the design most.

The important questions are request volume, acceptable response delay, context size, safety needs, and model cost. I would also ask how often answers can be reused and how quickly feedback data must appear.

These answers change how much we rely on Response Cache, how large the Inference Queue can become, and how Model Router chooses a model.

The Client sends the prompt to API Gateway. This is the public entry point.

Auth + Rate Limits checks access and controls how many requests one user can send. Prompt Validator checks the request format. Input Safety Checks blocks unsafe input before expensive model work begins.

These early checks protect the rest of the system. They also prevent invalid requests from using GPU capacity.

The LLM Orchestrator controls how the answer is prepared.

It first checks Response Cache. On a safe cache hit, the cached answer bypasses context building, routing, the queue, and GPU Model Serving. It still passes through Output Safety Checks before returning to the user.

On a cache miss, Context Manager loads conversation history, files, or retrieved information from Context Sources. Those sources include Conversation Store, Read Replicas, Object Storage, and Optional RAG Search. RAG means searching stored information before building the prompt.

Prompt Builder combines the prompt and context. Model Router then selects a model path. Configuration Store provides model versions and routing policy. This policy can change when latency, quality, or cost requirements change.

The request enters Inference Queue before GPU Model Serving.

The queue absorbs short traffic spikes. It also prevents too many requests from reaching the GPUs at once. GPU Model Serving generates the answer.

Output Safety Checks reviews the generated content. Response Formatter creates the final response shape. Streaming Gateway sends the answer back to Client as a streaming response.

The likely bottlenecks are Inference Queue, GPU Model Serving, large context loading, and Optional RAG Search. Observability & Monitoring should show where delay and errors are growing.

The main response should not wait for reporting tasks.

Client feedback goes through Feedback API to Event Bus. LLM Orchestrator also sends events to Event Bus. Output Safety Checks sends a safety decision event.

Event Bus sends work to Usage & Billing, Analytics, Audit Logs, and Evaluation & Feedback. These tasks run in the background.

If processing fails, the event moves to Failed Events. Retry with Backoff waits longer between attempts. After repeated failure, the event goes to DLQ for later review.

Stateless services can scale horizontally by adding more copies. Read Replicas can handle more context reads. GPU Model Serving can also add capacity, but GPUs are expensive.

Caching reduces response time and GPU work. The queue improves stability during spikes, but a long queue increases user wait time. Multi-AZ deployment, health checks, and failover improve availability, but they increase cost.

The key design choice is not one fixed setup. The system should change its cache rules, routing policy, queue limits, and capacity as requirements change.

At a high level, Instagram lets users post photos or videos, follow people, and read a personal home feed. The main challenge is keeping feed reads fast while uploads, follows, likes, comments, and background processing continue. I would explain the design in three parts: request routing, core data flows, and background work. Clients pass through DNS, the CDN, and the API Gateway. Core services use separate stores and Redis caching. The main trade-off is faster precomputed feeds versus extra storage and background processing.

The goal is to support posting, following, and fast home-feed reads. The difficult part is that these actions use different kinds of data. Photos and videos are large files. Follow relationships form a graph. Feed requests must remain quick even while new events arrive. The diagram separates the solution into client routing, core services, storage, an event stream, and background workers.

1. Which user flows and system capabilities are required for the first version?
2. What traffic, data volume, latency, and availability targets should I design for?
3. Which consistency, security, geographic, and cost constraints matter most?

I would begin with the path from the client. Users can open the iOS app, Android app, or web client. DNS finds the correct network destination. The CDN serves nearby media and helps reduce repeated delivery work.

Requests then reach the API Gateway layer. The Load Balancer spreads traffic across available service instances. The WAF filters harmful requests. Rate limiting stops one user from sending too many requests. The Auth Service checks the user identity before protected actions continue.

For posting, the Post Service handles the upload request and post metadata. Metadata means details such as the post owner and file location. The Media Service processes the photo or video. The final media file is stored in Media Storage, which is object storage for large files.

The Post Metadata DB stores post details. The User Service manages profiles and following information. The Social Graph Service handles follow and unfollow actions. The Activity Service handles likes and comments. The Notification Service handles user notifications.

For the home feed, the Feed Service creates the user timeline. The Social Graph Service provides the follow relationships needed for that work. The Feed Builder precomputes feeds in the background. Precompute means preparing feed results before the user asks for them.

Redis is used as the Cache. It keeps feed data and other hot data that users request often. A cached feed is faster to read than rebuilding the timeline each time. The Graph DB stores the follow graph. The User DB stores user information.

Core services publish events to the Event Bus or streaming system. The diagram shows events such as Post Created, Like Commented, and User Followed. These events let slow work happen after the main request.

The Media Processor resizes and transcodes media. Transcoding means changing media into useful delivery formats. The Indexing Worker updates the Search Index. The Notification Worker creates notifications. The Analytics Worker processes activity data. This separation keeps user-facing requests responsive.

The Load Balancer helps the service spread traffic. The CDN reduces repeated media delivery. Redis lowers repeated database work. Separate databases match different data needs. The Search Index supports fast search and explore requests.

The stated goals are low feed latency, high availability, horizontal scaling, fault tolerance, and a consistent experience. Horizontal scaling means adding more service instances as traffic grows. The main trade-off is feed precomputation. It makes reads fast, but it uses more cache space and background work. The event stream also improves responsiveness, but some background results may appear slightly later.

At a high level, this system lets users publish media, follow people, and read a home feed. The main challenge is keeping feed reads fast when one post may update many follower feeds. I would explain three flows: posting content, changing follow relationships, and building and reading feeds. Media goes through Object Storage and the CDN. New-post and follow updates enter the Event Queue. The Feed Fan-out Service updates the Feed Store and Home Feed Cache. The trade-off is that background feed updates may appear after a short delay.

The goal is to let users publish photos or videos, follow other users, and load a home feed quickly. The difficult part is feed fan-out. One new post may need to appear in many follower feeds. The diagram handles this by separating posting, follow updates, background feed building, and home-feed reads.

1. Which user flows and system capabilities are required for the first version?
2. What traffic, data volume, latency, and availability targets should I design for?
3. Which consistency, security, geographic, and cost constraints matter most?

I would say that posting and following create data, while feed reading happens much more often. The design separates these flows so each part can scale independently.

The Client App sends requests through the API Gateway. The Auth Service checks the user and sends the request to the correct service. Post Service handles new posts. Follow Service handles follow changes. Feed Service handles home-feed reads.

For a new post, the request reaches Post Service after authentication. Post Service sends the media to Media Upload Service. That service stores the media files in Object Storage.

Object Storage provides the origin media to the CDN. The CDN then serves images and videos directly to the Client App. This keeps large media files away from the main application services.

Post Service separately saves post metadata in Post Metadata DB. Metadata means the information that describes the post. Read Replicas provide extra read copies, so heavy reads do not overload the main database.

Post Service also sends a "New post event" to the Event Queue. This starts feed work without making the user wait for every follower feed update.

For a follow or unfollow request, Auth Service sends the call to Follow Service. Follow Service saves the follow or unfollow edge in Social Graph DB.

An edge means one relationship between two users. Follow Service also sends a "Follow graph update" to the Event Queue. This lets background feed work react when follow relationships change.

The Event Queue holds new-post and follow-graph events. This work is asynchronous, which means it runs in the background after the main request can finish.

Feed Fan-out Service receives this work. It reads followers from Social Graph DB. It then pushes post IDs into Feed Store for the correct follower feeds.

Feed Fan-out Service also warms or invalidates Home Feed Cache. Warming means placing useful feed data into the cache early. Invalidating means removing cached data that may now be old.

For a home-feed request, the Client App goes through API Gateway and Auth Service. The request then reaches Feed Service.

Feed Service reads Home Feed Cache first. On a cache hit, Home Feed Cache returns the cached result to Feed Service. On a cache miss, Home Feed Cache reads the required feed entries from Feed Store.

Feed Store sends feed items to Feed Service. Feed Service returns the final "Feed JSON" response to the Client App. The Client App then loads the related images and videos from the CDN.

The service boxes are stateless. This means any service copy can handle a request. We can run several copies behind the gateway for better availability.

The Event Queue smooths sudden fan-out spikes. Read Replicas and Home Feed Cache absorb heavy read traffic. Object Storage and the CDN improve media availability.

The main trade-off is delayed feed updates. A new post may take a short time to reach every follower feed because fan-out runs in the background. We accept that delay because posting stays responsive and feed reads stay fast.

At a high level, this system watches product prices and alerts users when their target price is reached. The main challenge is checking many retailer pages without making the user wait. I would explain it in three flows: saving watch rules, running scheduled price checks, and delivering notifications. The API stores watchlists and product details. The Scheduler fills the Check Queue, workers fetch and normalize prices, and the Threshold Evaluator creates notification events. The trade-off is that background work improves reliability but can delay alerts.

The goal is to track product prices, keep price history, and notify users when a saved threshold is met. The difficult part is that retailer pages may be slow, unavailable, or use different data formats. The design separates user requests from background price checks. It also separates price processing from notification delivery.

1. Which user flows and system capabilities are required for the first version?
2. What traffic, data volume, latency, and availability targets should I design for?
3. Which consistency, security, geographic, and cost constraints matter most?

I would start by saying that users create watch rules for products. The system saves those rules and checks prices later in the background. This keeps the Client App responsive because it does not wait for retailer requests.

The design has three main parts. First, it saves the product and threshold. Second, it schedules and processes price checks. Third, it sends alerts when the threshold is met.

For the user path, the User opens the Client App. The request goes through the API to the Watchlist + Threshold API. This service saves the product and target threshold in the Watchlist Store.

It also saves tracked product metadata in the Product Catalog. The Scheduler reads active subscriptions and products that need checks.

The Scheduler creates scheduled jobs and sends them to the Check Queue. Price Fetch Workers take jobs from the queue. The Autoscaler watches backlog and adds or removes workers when needed.

Workers fetch prices from Retailer Pages / APIs. Raw fetched price data goes to the Parser + Normalizer. The normalized price is stored in the Price History Store.

The Threshold Evaluator compares latest prices with prior prices and checks threshold settings. When the threshold is met, it creates a notification event.

The Notification Queue stores notification work. Notification Delivery sends alerts through Email / Push / Webhook.

Network or parsing failures go to the Retry Queue. Failed work can be retried. Jobs that fail too many times move to the DLQ. Monitoring watches the system and raises operator alerts.

The benefit is that slow retailer calls do not block users. The downside is that queued work can delay alerts.

At a high level, this system translates Facebook content so international users can read posts in their preferred language. The main challenge is returning translations quickly while also choosing the right translation provider and keeping results accurate. I would explain the design in three parts: the user request flow, the translation and storage flow, and the background quality flow. The system uses caching for speed, queues for background work, and stored translations for reuse. The trade-off is more system complexity.

The goal is to build a service that translates Facebook content for users around the world. The system must return translated content quickly while handling language detection, provider selection, translation storage, quality checks, and background processing. The design separates the fast user request path from slower translation jobs and feedback processing.

1. Which user flows and system capabilities are required for the first version?
2. What traffic, data volume, latency, and availability targets should I design for?
3. Which consistency, security, geographic, and cost constraints matter most?

The system receives content requests from international users and returns localized content. The main idea is to avoid translating the same content repeatedly. The system checks existing translations first and creates new translations only when needed.

The diagram separates the design into three areas. The first area is the user request flow. The second area is translation processing and storage. The third area handles background work and quality improvement.

The request starts from the International User and moves through the Facebook App / Web. The API Gateway provides the entry point for requests. Then the Content Resolver finds the original content that needs translation.

The Translation Platform controls the translation process. The Request Router sends the request to Cache Check. The system checks the Translation Cache first because many users may request the same translation.

On a cache hit, the existing translation can be returned faster. If the cache misses, the request moves to Language Detector. This identifies the source language before translation starts.

The Provider Router selects the translation provider based on language needs, latency, cost, and quality rules. The Locale Glossary + Rules component provides language-specific guidance. The selected provider creates the translation.

The Quality Gate checks the translated result. Approved translations are saved in the Translation Store. The Response Assembler prepares the final localized response and sends it back to the Facebook client.

The Source Content Store keeps the original Facebook content. The Translation Cache stores commonly requested translations for faster responses. The Translation Store keeps approved translation results that can be reused later.

The cache improves speed, but it is not the main source of translation data. If the cache does not contain a result, the system can continue using the translation flow and stored data.

Some work does not need to block the user response. New content events and refresh work are sent to the Async Translation Queue. Background workers process these tasks.

The Pretranslation Worker prepares translations for popular locales. The Retry Worker handles temporary translation failures. The Autoscaled Worker Pool allows more workers when background demand increases.

Users can report translation problems through Feedback API. The Evaluation Pipeline uses this feedback to improve routing decisions. This helps the Provider Router make better choices over time.

The system scales by separating user traffic from background translation work. APIs and workers can scale independently. The cache reduces repeated translation requests. The queue prevents slow translation jobs from blocking users.

Provider failures can happen during translation. Retry processing helps handle temporary failures. If a translation is not ready, the system may need more time before the final result is available.

The benefit is faster responses and better reuse of completed translations. The downside is that the system has more components to manage, including caches, queues, workers, and quality checks.