Meta .NET Developer Interview Questions & Answers

I would first use a dictionary to add all weights for each key. Then I would sort the distinct keys by total weight descending. If two totals are equal, I would sort those keys in ascending ordinal lexicographic order. Dictionary equality checks keep different keys separate even when their hash codes collide. The expected time is O(n + m log m), where m is the number of distinct keys, and the auxiliary space is O(m).

The input contains pairs of a text key and a numeric weight. The same key can appear more than once. We first add all weights that belong to the same key. Then we rank the distinct keys from the largest total weight to the smallest. When two totals are equal, we order those keys by ascending ordinal lexicographic order. A dictionary is a good fit because it keeps one running total for each key. After aggregation, we only need to sort the distinct dictionary entries.

1. Should equal totals use case-sensitive ordinal string ordering?
2. Can weights be negative or zero?
3. Can the input be empty?
4. Can accumulated totals be large enough to require long?

The input is a sequence of pairs. Each pair contains a string key and a numeric weight. The output contains each distinct key once. Keys with larger accumulated weights come first. If two keys have the same accumulated weight, their keys are compared in ascending ordinal lexicographic order.

For the diagram example, the input is (apple, 3), (banana, 2), (apple, 5), (carrot, 4), (banana, 2), and (date, 4). The final output is apple, banana, carrot, date.

Use a Dictionary<string, long> called weightByKey. Each dictionary key is one input key. Its value is the running total of all weights seen for that key.

The central invariant is: after processing any prefix of the input, weightByKey stores the exact accumulated weight for every key seen in that prefix. Repeated keys update the same entry. If two different keys happen to have the same hash bucket, Dictionary still keeps them separate by checking key equality.

Start with an empty dictionary.

Process (apple, 3). Apple is new, so its total becomes 3.

Process (banana, 2). Banana is new, so its total becomes 2.

Process (apple, 5). Apple already has 3, so its total becomes 3 + 5 = 8.

Process (carrot, 4). Carrot is new, so its total becomes 4.

Process (banana, 2). Banana already has 2, so its total becomes 2 + 2 = 4.

Process (date, 4). Date is new, so its total becomes 4.

The final totals are apple = 8, banana = 4, carrot = 4, and date = 4.

Sort the dictionary entries by total weight descending. Apple comes first because 8 is larger than 4. Banana, carrot, and date all have total 4, so the tie rule is used. Ascending ordinal lexicographic order gives banana before carrot before date.

The final ranked result is apple, banana, carrot, date.

The dictionary invariant guarantees that each stored value is the sum of all processed weights for its key. After the complete input has been processed, every stored total is final. Sorting by total descending gives the required weighted ranking. Applying the ordinal key comparison only when totals are equal gives the required tie order. Therefore the returned keys follow both ranking rules.

The method receives IEnumerable<(string Key, long Weight)>. It creates a Dictionary<string, long>. For each pair, it creates a zero total when the key is first seen, then adds the current weight. After aggregation, OrderByDescending sorts entries by total weight. ThenBy with StringComparer.Ordinal resolves equal totals by key. Select keeps only the keys, and ToList returns the ranked list.

Let n be the number of input items and m be the number of distinct keys. Dictionary lookup and insertion are O(1) on average, so aggregation takes O(n) expected time. Sorting m distinct entries costs O(m log m). The total expected time is O(n + m log m). Auxiliary space is O(m).

An empty input returns an empty list. Repeated keys accumulate into one total. Zero and negative totals still follow descending numeric order. Equal totals use ordinal lexicographic ascending order. The code uses long for larger accumulated totals.

Use two phases. First, aggregate every occurrence of the same key into one running total in a Dictionary<string, long>. The invariant is that after each processed item, the dictionary contains the exact accumulated weight seen so far for every key. Repeated keys update their existing total. Hash collisions do not combine different keys because Dictionary uses equality checks to distinguish them. Second, sort the distinct dictionary entries by total weight descending and then by key with StringComparer.Ordinal ascending. Finally, return only the keys.

Let n be the number of input items and m be the number of distinct keys. Dictionary lookup and insertion are O(1) on average, so building the totals takes O(n) expected time. Sorting the m distinct entries takes O(m log m). Therefore the complete expected time is O(n + m log m). The dictionary and ranked result grow with the number of distinct keys, so the auxiliary space is O(m). Dictionary performance depends on average hash-table behavior, not guaranteed constant-time worst-case operations.

A common mistake is sorting the original input records before first combining repeated keys. Another is replacing a previous weight instead of adding to the running total. A candidate may also forget the secondary ordering rule and leave equal totals in an unspecified order. Another mistake is assuming a hash collision means two different keys should be combined. Dictionary still compares keys for equality. Finally, claiming O(n) total time is incorrect because sorting the m distinct keys costs O(m log m).

State the two ordering rules before writing code: total weight descending first, then key ascending with StringComparer.Ordinal for equal totals. Then explain that the dictionary produces exactly one accumulated total per distinct key. This makes the correctness argument and the final LINQ ordering easy to verify.

I would treat each scrambled ticket as a directed link from one place to the next. I build a dictionary from each source to its destination and a set containing every destination. The unique source that never appears in the destination set is the start. From there, I repeatedly follow the dictionary links until there is no outgoing record. I also verify that every ticket record was consumed exactly once. This takes O(n) expected time and O(n) auxiliary space.

The input is a scrambled collection of directed ticket records. Each record has a from place and a to place. The to place comes immediately after the from place in the final trip. We need to rebuild one continuous order from the first place to the last. The key idea is to find the only source that never appears as a destination. Then we follow each next connection until the trip ends. A dictionary gives fast successor lookups, and a set helps identify the unique start.

1. Can I assume a valid input should form one complete directed chain?
2. Should I reject invalid data such as duplicate sources, cycles, or disconnected records?
3. Should the returned result contain every endpoint from the first source through the final destination?

Each input record is a directed pair (from, to). It means to immediately follows from. The records can arrive in any order. We must return the complete endpoint sequence from the first endpoint to the last endpoint. In the diagram, the scrambled records are (SFO, LAX), (DEN, SEA), (LAX, DEN), and (SEA, BOS). The recovered order is SFO → LAX → DEN → SEA → BOS.

I create nextByFrom, a dictionary that stores from → to. For the example, it contains SFO → LAX, LAX → DEN, DEN → SEA, and SEA → BOS. I also create a destination set containing {LAX, DEN, SEA, BOS}. The start is the unique source that does not appear in this destination set.

I check every source stored in nextByFrom. SFO is the only source that does not appear in the destination set, so SFO is the start. If more than one source satisfies this condition, there is no unique chain start. If no source satisfies it, the records cannot form the required one-way chain from a unique starting endpoint.

Start with SFO. The dictionary gives nextByFrom["SFO"] = "LAX", so the order becomes SFO → LAX. Next, nextByFrom["LAX"] = "DEN", so the order becomes SFO → LAX → DEN. Then nextByFrom["DEN"] = "SEA", giving SFO → LAX → DEN → SEA. Next, nextByFrom["SEA"] = "BOS", giving SFO → LAX → DEN → SEA → BOS. BOS has no outgoing record, so traversal stops.

The important invariants are the same ones shown in the diagram. Each source has at most one successor. Each non-start endpoint has one predecessor in a valid chain. Exactly one source never appears as a destination, and that source is the start. Following successors from the start forms one acyclic chain. Finally, the traversal must consume every input record exactly once. These properties make the reconstructed order unambiguous for a valid input.

The code builds nextByFrom with Dictionary<string, string> and stores destinations in HashSet<string>. TryAdd rejects a duplicate source because a valid chain cannot give one source more than one successor. The code then finds the unique dictionary key that is missing from the destination set. Starting there, it follows TryGetValue links, appends each destination, and counts how many records were consumed. A count larger than the dictionary size detects a cycle. A final count check rejects records that do not all belong to the reconstructed chain.

Building the dictionary and destination set takes O(n) expected time because Dictionary and HashSet operations are O(1) on average. Finding the start and following the chain also take O(n) expected time. Therefore, the overall expected time is O(n). The dictionary and set grow with the input, so auxiliary space is O(n). Relevant cases include a single record, a duplicate source, no unique start, a cycle, and disconnected records.

The key insight is that the first endpoint appears as a source but never as a destination. I store every directed record in a dictionary called nextByFrom, where each key is a source and its value is the immediate destination. I also store every destination in a hash set. The unique dictionary key missing from the destination set is the start. From that start, repeatedly following nextByFrom[current] reconstructs the sequence. The central invariants are that each source has at most one successor, there is exactly one start, following successors forms one acyclic chain, and every input record is consumed exactly once.

Let n be the number of ticket records. Building the dictionary and destination set takes O(n) expected time. Dictionary and HashSet lookup and insertion are O(1) on average, so the overall hashing-based bound is expected rather than guaranteed worst-case O(n). Finding the start takes O(n), and following the chain takes O(n). Overall expected time is O(n). The dictionary and destination set can each hold O(n) values, so auxiliary space is O(n). The returned order contains n + 1 endpoints.

A common mistake is trying to sort the records instead of following their directed relationships. Another is building the source-to-destination dictionary but not collecting destinations, which makes the unique start difficult to identify. Candidates may also overwrite a duplicate source instead of rejecting the ambiguous successor. Another mistake is stopping when an endpoint has no successor without checking whether every record was consumed. Finally, it is incorrect to describe Dictionary and HashSet operations as guaranteed O(1); their lookup and insertion operations are O(1) on average.

State the invariant before writing code: the start is the unique source that never appears as a destination, and every valid source has at most one successor. Then trace SFO → LAX → DEN → SEA → BOS while writing the dictionary traversal.

I would treat the 20 supplied variants as raw cases and convert each one to a canonical key based on the equivalence rule from the problem. I store those keys in a HashSet. If two variants are equivalent, they produce the same key, so the set counts that equivalence class only once. I process all variants once. In general, the expected time is O(n · C), where C is canonicalization and hashing cost, and the auxiliary space is O(u · S).

The problem gives exactly 20 candidate variants. Some variants may represent the same logical case. We need to count or compare the distinct cases without counting equivalent variants more than once. The main idea is to convert each variant into one standard representation, called a canonical key. Equivalent variants must produce the same key. We then keep the unique keys in a set. The diagram does not define the actual contents of all 20 variants, so it correctly does not give one final numeric distinct count.

1. What exact rule decides whether two variants are equivalent?
2. What canonical representation should we use for each equivalence class?
3. Do you want only the number of distinct classes, or also the variants inside each class?

The input is exactly 20 supplied variants. The diagram labels them symbolically as V1 through V20 because their real contents are not specified. The output is the number of distinct equivalence classes. This is also the number of unique canonical keys. We must use the equivalence rule defined by the problem. We must not invent a rule such as ignoring order unless the problem explicitly says that order does not matter.

For each raw variant, we compute one canonical key. A canonical key is the standard representation of that variant's equivalence class. Equivalent variants must produce the same key. The C# solution stores those keys in a HashSet<string>. A hash set keeps only one copy of an equal key, so it naturally prevents double-counting.

We visit each of the 20 variants once. For each variant, we call the supplied canonicalization function. We then add the returned key to the hash set. If the key is new, one new equivalence class has been discovered. If the key already exists, HashSet.Add leaves the set unchanged, so that equivalent raw variant is not counted again.

The diagram shows V1 mapping to K1. K1 has not been seen, so the distinct-key count becomes 1. V2 maps to K2. K2 is new, so the count becomes 2. V3 maps to K1. K1 already exists, so the count stays 2. The middle variants are intentionally omitted from the symbolic trace. V20 is shown mapping to K7, but the diagram marks whether that key was already seen as unknown because the omitted mappings are not specified. Therefore, the final result remains the number of unique canonical keys rather than an invented numeric value.

The invariant is that after processing any prefix of the input, the HashSet contains exactly one canonical key for each distinct equivalence class seen so far. If two raw variants are equivalent, a correct canonicalization function gives them the same key. The set therefore stores that class only once. If two variants are not equivalent, a correct canonicalization function gives them different keys. After all 20 variants are processed, the set count is exactly the number of distinct equivalence classes.

The method receives the 20 variants and a canonicalize function. It checks both arguments for null and verifies that exactly 20 variants were supplied. It creates an empty HashSet<string>. It processes each variant, computes its canonical key, and adds that key to the set. Duplicate keys do not create additional entries. The method finally returns uniqueKeys.Count. The Main method prints the exact symbolic trace shown by the diagram without inventing the mappings that the diagram intentionally leaves unspecified.

Let n be the number of variants. The diagram uses n = 20. Let C be the cost of canonicalizing and hashing one variant. We process each variant once, so the expected time is O(n · C). HashSet lookup and insertion are O(1) on average after a key is produced. If u unique keys are stored and their average size is S, auxiliary space is O(u · S). If all 20 variants are equivalent, the result is 1. If all 20 are non-equivalent, the result is 20. Mixed duplicates are counted once per canonical key.

The key insight is to count equivalence classes instead of raw variants. Each raw variant is converted to a canonical key using the equivalence rule defined by the problem. The central invariant is: after processing any prefix of the input, the HashSet contains exactly one canonical key for every distinct equivalence class seen in that prefix. Equivalent variants map to the same key, so they cannot increase the distinct count more than once. Non-equivalent variants must map to different keys. This makes a hash set a direct fit for removing equivalent duplicates.

Let n be the number of variants. The diagram uses exactly 20. Let C be the cost of canonicalizing and hashing one variant. We process every variant once, so the expected time is O(n · C). HashSet lookup and insertion are O(1) on average after the key is produced. Let u be the number of unique canonical keys and S be the average stored key size. The auxiliary space is O(u · S). This is expected-time wording because C# hash-based collection operations are average O(1), not guaranteed worst-case O(1).

A common mistake is inventing an equivalence rule, such as saying order does not matter, when the problem has not defined that rule. Another mistake is counting all 20 raw variants instead of counting unique canonical keys. A candidate can also write a bad canonicalization function that gives different keys to equivalent variants or the same key to non-equivalent variants. Another mistake is inventing a final numeric answer even though the diagram does not define the omitted mappings. Finally, do not claim that HashSet operations are guaranteed O(1); they are O(1) on average.

State the invariant early: one canonical key represents one equivalence class. Then use the exact V1 → K1, V2 → K2, V3 → K1 trace to show why the distinct count does not increase when an equivalent variant appears again.

At a high level, I would design the Facebook feed API around reading the feed, creating posts, and interacting with feed items. Clients send HTTPS requests with a JWT to an ASP.NET Core API Gateway. The gateway validates the token, rate limits traffic, routes the request, and returns the JSON response. The Feed Service handles the feed endpoints, uses the shown data stores and Redis cache, and publishes Kafka events for background work. The trade-off is more infrastructure and operational complexity in exchange for better scaling, security, caching, and asynchronous processing.

This question asks us to design how Facebook clients use the feed. A user should be able to open the feed, load more items, refresh it, create a post, like or comment on a post, share it, and manage feed choices. The client also needs a clear response containing the feed items and information for loading the next page. The main challenge is keeping these actions fast, safe, and easy to scale. I would explain the design in the same order as the diagram, from the client to the gateway, Feed Service, storage, and background workers.

• Do we need both feed reads and post interactions?
• Should the feed support incremental loading and explicit refresh?
• Do we need preferences, seen state, and reporting?
• Should fanout, notifications, search, and analytics be asynchronous?

I would start with the clients. The diagram supports iOS, Android, web, and other clients. The Auth Service handles login or signup, token issuance, and user profile information. After authentication, it returns a JWT to the client. A JWT is a signed token that represents the authenticated user.

For a feed request, the client sends an HTTPS request with that JWT to the API Gateway. HTTPS protects the request while it travels over the network. The security section requires HTTPS everywhere using TLS 1.2 or later.

The API Gateway is an ASP.NET Core component. It validates the JWT, applies rate limiting, performs request routing, shapes responses, uses Redis caching, and records logging and metrics. Rate limiting protects the API from excessive traffic.

The request moves from the client to the gateway. The gateway forwards it to the Feed Service. The Feed Service returns its service response to the gateway. The gateway then sends an HTTPS JSON response back to the client.

The main read endpoint is GET /feed, which gets the news feed. GET /feed/{feedId} gets a single feed. The diagram uses GET /feed?since_id=123 for pagination. GET /feed/refresh refreshes the feed. GET /feed/preferences gets the user's feed preferences.

The client-facing GET /feed response contains status, data, and paging. Inside data.feed, each item contains post_id, an actor with id, name, and profile_picture, content, media, stats, privacy, created_at, and actions. The stats object contains values such as like_count, comment_count, and share_count. The actions object tells the client whether the viewer can like, comment, or share. The paging object contains next and has_more for the next page.

For writes, POST /feed creates a post. POST /feed/{postId}/like likes a post. POST /feed/{postId}/comment adds a comment. POST /feed/{postId}/share shares a post. DELETE /feed/{postId} deletes a post. POST /feed/preferences updates preferences.

The diagram also shows POST /feed/seen to mark items as seen and POST /feed/report to report content. These requests follow the same client-to-gateway-to-Feed-Service path.

The Feed Service reads and writes the Data Stores boundary. The Feed Store uses Cassandra or ScyllaDB for feed items and metadata. The User Graph Store uses Neo4j or JanusGraph for follow relationships, blocks, and mutes. The Media Store uses blob or object storage for images, videos, and thumbnails. Redis is used for feed caching and counters.

The diagram shows data returning from the stores to the Feed Service. The Feed Service then builds the service response and sends it back through the gateway.

The Feed Service also sends events to the Kafka Event Pipeline. The visible events are PostCreated, PostLiked, CommentAdded, PostShared, and PostDeleted.

Consumers and Workers process those events for feed fanout to followers, notifications, search indexing, and analytics or machine learning. This is asynchronous work, so it stays outside the direct client response path. That keeps the synchronous feed request focused on returning the API result.

The diagram defines common errors. 400 means invalid parameters. 401 means the token is missing or invalid. 403 means the requested action is not allowed. 404 means the resource was not found. 429 means the caller was rate limited. 500 means an internal server error, with the guidance to try again later.

Security and governance also include JWT authentication using OAuth 2, privacy filters for personally identifiable information, rate limiting and abuse protection, input validation and sanitization, plus audit logs and monitoring.

The benefit is a clear API boundary with caching and asynchronous processing. The downside is additional operational complexity because the design includes a gateway, several data stores, Redis, Kafka, and background workers.

The main design choice is to keep client calls simple while placing shared work behind the API Gateway and Feed Service. The gateway gives one place for JWT validation, rate limiting, routing, response shaping, caching, logging, and metrics. Redis can make feed access faster, but cached data can add freshness concerns. Kafka moves fanout, notifications, search indexing, and analytics outside the direct response path. The benefit is that these background jobs do not need to finish before every client response. Different stores also handle different kinds of data, including feed items, relationships, media, and cached counters. The downside is more infrastructure to deploy, operate, and monitor. We accept this complexity because a large feed needs strong scaling, security controls, caching, and separation between synchronous requests and asynchronous work.

At a high level, I would build one access-control API for users, roles, permissions, assignments, and authorization checks. Callers send HTTPS requests through an ASP.NET Core API Gateway with a JWT. The gateway validates the token, checks policies or scopes, and forwards the caller context to the ASP.NET Core Access Control Service. That service evaluates roles and permissions using the relational database and may cache policy data in Redis. Responses return through the gateway. The main trade-off is stronger centralized security and auditing versus extra gateway, cache, and operational complexity.

This question asks us to design a service that controls who can do what. We need to manage users and define groups of allowed actions. We also need to connect users to those groups and check access when a caller asks to use something. The caller must first prove its identity. Then the system decides whether that caller has permission for the requested action. The diagram uses a gateway, an access-control service, stored access data, caching, logging, and security support to solve this problem.

• Are the callers people, internal services, or both?
• How often can roles, permissions, and assignments change?
• How quickly must an authorization decision return?

I would separate access control into users, roles, permissions, assignments, and authorization checks. The ASP.NET Core Access Control Service owns these business operations.

For users, the diagram shows GET /api/users, POST /api/users, and GET, PUT, or DELETE /api/users/{id}. Roles use GET /api/roles, POST /api/roles, and GET, PUT, or DELETE /api/roles/{id}. It also shows POST /api/roles/{id}/users for assigning users to a role.

Permissions use GET /api/permissions, POST /api/permissions, and GET, PUT, or DELETE /api/permissions/{id}. Assignments use GET /api/assignments, POST /api/assignments, and DELETE /api/assignments/{id}.

The request first reaches the ASP.NET Core API Gateway over HTTPS. The request carries a JWT, which is a signed token containing caller information such as sub, roles, and scopes.

The gateway performs JWT validation. The diagram shows the gateway validating the token with the external Identity Provider through JWKS or introspection and receiving a token-validation response. JWKS means public signing keys that can be used to verify a token. The gateway also handles routing, rate limiting, policy or scope authorization, request and response logging, and correlation or tracing.

Authentication and authorization are different. Authentication checks who the caller is. Authorization checks what that authenticated caller may do.

After the gateway accepts the request, it forwards the valid request to the Access Control Service. The diagram shows the forwarded context containing the user context, roles, and scopes.

The service contains a Users & Roles API, Permissions API, and Authorization API. The Authorization API checks access using a user, resource, and action. It also enforces policies and evaluates role or permission claims.

For a direct decision, the diagram shows POST /api/authorize/check. Its body contains userId, resource, and action. The diagram also shows GET /api/authorize/policies for authorization policies.

The Access Control Service reads and writes access-control data in the relational database. The database stores users, roles, permissions, and assignments. The diagram shows ADO.NET or Entity Framework Core for the service-to-database access.

The service can also get or set cached policies and permissions in Redis. The service receives the cache result back from Redis. This can reduce repeated database work for authorization decisions.

The relational database remains the main stored data source shown in the diagram. Redis is an optimization for cached policies and permissions.

After the Access Control Service finishes the operation, it sends the service response back to the API Gateway. The gateway then returns the HTTPS response to the original caller.

The diagram explicitly shows examples such as 200, 403, and 404 on this response path. A 200 indicates a successful operation. A 403 means the caller is authenticated but is not allowed to perform the requested action. A 404 means the requested resource was not found.

The important point is that the response travels back in the reverse service path: Access Control Service to API Gateway, then API Gateway to the caller.

The design also includes supporting components outside the main synchronous response path. Audit & Logging records the audit trail, security events, and access decisions. The diagram names Serilog or Seq for this area.

Monitoring & Tracing uses OpenTelemetry for metrics, distributed tracing, and alerts. Secrets Management stores signing keys, database credentials, and API secrets.

The Message Broker is optional. The diagram names RabbitMQ or Azure Service Bus. It can carry user or role change events, support cache invalidation, and support asynchronous audit processing. This broker does not replace the normal request and response path.

The diagram also exposes GET /health, GET /version, and GET /open-api.json. The stated security principles are least privilege, deny by default, secure by design, auditing, and encryption in transit and at rest.

The benefit of this design is clear responsibility. The API Gateway handles routing, rate limiting, JWT validation, early policy or scope checks, logging, and tracing. The Access Control Service owns users, roles, permissions, assignments, and access decisions. Redis can make repeated policy or permission checks faster and reduce database work. The downside is cache correctness. A changed role or permission can make old cached data incorrect. The optional message broker can help with change events and cache invalidation, but it adds another system to operate. Central logging and tracing improve security and support, but they also add storage and operational work. We accept these costs because access control needs clear ownership, consistent checks, and a useful audit trail.

At a high level, I would design Dropbox around file storage, sharing, and efficient synchronization. Clients send HTTPS requests with a JWT through an API Gateway. The gateway handles TLS termination, rate limiting, authentication, authorization, routing, and request or response logging. Core services manage files, shares, users, uploads, metadata, and sync. File content goes to immutable blob storage, while metadata stays in SQL. Domain events drive background work such as scanning, indexing, previews, retention, quotas, and notifications. The trade-off is greater operational complexity for better scaling, strong metadata consistency, and clear service ownership.

This question asks us to design how people store files, share them, and keep several devices updated. We need to show where file content lives, where information about each file is stored, and how sharing permissions work. We also need a practical way to upload large files and send only new changes during synchronization. The design should protect requests, support many clients, and move slow work away from the main request. I will follow the diagram from the clients through the gateway, core services, storage, and background processing.

• Should we support both personal files and shared files?
• How large can files become, and should large uploads be resumable?
• How quickly should changes appear on another device?
• Do we need versions, trash and restore, and shared links?

I would start with the client boundary. The diagram supports a Web App, Mobile App, Desktop Client, and CLI or Third Party Integrations. Clients use the Identity Provider for login and consent. The Identity Provider uses OAuth 2.0 or OpenID Connect and owns authentication, authorization, and token issuance. API requests then reach the API Gateway over HTTPS with a JWT. The gateway terminates TLS, validates authentication and authorization information, applies rate limiting, routes requests, and records request and response logs. The client response returns through the gateway as HTTPS JSON.

The gateway sends requests to Dropbox Core Services using gRPC or HTTPS with mTLS. Here, mTLS means the connection is encrypted and both sides can authenticate each other. The File Service manages files, folders, metadata, versioning, trash, and restore. The Sharing Service manages shares, links, permissions, and access control. The Sync Service owns delta sync, cursors, change tracking, and conflict resolution. The User Service manages profiles, quotas, preferences, and devices. The Upload Service creates upload sessions, manages chunks, and commits or finalizes uploads. The Metadata Service manages file metadata, versions, checksums, and retention. Service responses return toward the gateway as Protobuf or JSON.

I would store large file content separately from metadata. Dropbox Core Services upload and download file content over HTTPS to Object Storage. The Blob Store may use S3, GCS, or Azure Blob and stores files as immutable blobs. Blob responses return to the core services. Metadata uses the Metadata Store, shown as a SQL Database with a primary and read replicas. It stores users, files, folders, shares, permissions, versions, devices, and sync state. Core services read and write this data through ADO.NET, and query results return to the services. This separation lets large file data scale differently from strongly consistent metadata.

For a large upload, POST /2/files/upload_session/start creates an upload session and returns session_id. POST /2/files/upload_session/append_v2 uploads a chunk and returns cursor. POST /2/files/upload_session/finish commits the file and returns file metadata. POST /2/files/download downloads file content and returns file bytes. POST /2/files/list_folder lists folder contents and returns entries. POST /2/files/list_folder/continue performs delta sync and returns entries plus a cursor. POST /2/sharing/create_shared_link creates a shared link and returns link metadata. The cursor lets a client continue from an earlier synchronization point instead of repeatedly requesting the full folder state.

Core services publish domain events asynchronously to the Event Bus, shown as Kafka or Pulsar. These events are separate from the synchronous client response path. Background Workers consume them. The Thumbnail Generator creates previews. The Virus Scanner scans uploaded files. The Indexing Worker extracts text and metadata. Retention and Lifecycle applies retention and cleanup. Quota Enforcer monitors usage and quotas. Index data is sent asynchronously to Search / Indexing, where Elasticsearch provides full-text search over files and metadata. Notifications are also published asynchronously for email, push, and in-app messages.

The diagram keeps metadata strongly consistent and uses high availability through multi-AZ deployment. File blobs are immutable, while version information is kept in metadata. It also calls for idempotent APIs for safe retries, fine-grained sharing and permissions, encryption in transit with TLS and at rest, and efficient delta-plus-cursor synchronization. The API Gateway owns JWT validation, authorization, rate limiting, and logging before routing requests. The diagram does not define specific HTTP failure codes, so I would not invent them. The main trade-off is complexity. Multiple services, an event bus, SQL metadata, blob storage, workers, indexing, and notifications require more operations work, but they let storage, sync, sharing, and background processing scale independently.

The main design choice is separating file bytes from metadata. Blob storage works well for large immutable files. SQL works well for users, folders, permissions, versions, devices, and sync state. Strong metadata consistency makes sharing and synchronization easier to reason about, but it needs more coordination. Upload sessions split large files into chunks. Delta sync with cursors avoids repeatedly sending the full folder state. The API Gateway centralizes TLS termination, JWT validation, authorization, rate limiting, routing, and logging. An Event Bus moves slow work to background workers. The benefit is clearer ownership and independent scaling. The downside is more services, events, storage systems, and operational work. We accept that complexity because file storage, sync, search, and background processing have different scaling needs.

At a high level, I would keep leaderboard reads on a fast Redis path and keep durable scores in Cassandra or MongoDB. The client sends an HTTPS request with a JWT through the API Gateway to the ASP.NET Core leaderboard service. Top-N reads use a Redis sorted set, while a player lookup uses a Redis hash for fast score and rank access. Score updates change Redis and are persisted asynchronously by background workers. The main trade-off is speed versus temporary delay between Redis, rank maintenance, and durable storage.

This problem is about showing the best game scores very quickly. It must also find one player’s score and rank without scanning every player. A player can request the top list, request their own result, or submit a new score. The design keeps common reads in Redis because Redis is fast. It keeps durable score data in Cassandra or MongoDB. It also checks the caller before routing requests to the leaderboard service. I will follow the diagram’s gateway, API, Redis, background worker, storage, and monitoring paths.

• Is each leaderboard separated by game, as shown by the gameId Redis keys?
• How fresh must a player’s rank be after scores change?
• Should score updates replace a score or increment it?

I would start with the three operations shown in the diagram. GET /leaderboard/top?limit=100 returns the top N players. GET /leaderboard/player/{playerId} returns one player’s rank and score. POST /leaderboard/score submits or updates a score with playerId, score, and metadata. These operations cover the main read and write needs of the leaderboard.

The game client sends an HTTPS request with a JWT to the API Gateway. The gateway handles rate limiting, authentication and authorization checks, routing, and request validation. The diagram also shows token validation through the Auth Service using JWKS or introspection. The Auth Service returns Token OK on the shown success path. The gateway then routes the request to the ASP.NET Core leaderboard service. The normal business response returns from the leaderboard service through the gateway to the client.

For the top leaderboard request, the service reads the Redis sorted set named leaderboard:{gameId}. The diagram shows the top-N read using ZRANGE. The sorted set keeps players ordered by score. Redis returns the requested top players to the leaderboard API. The service then returns that result through the gateway. This is the fast read path for showing the current leaders without querying the durable store for each request.

A player lookup uses the Redis hash player:{gameId}:{playerId}. The diagram shows this hash storing score, rank, and updatedAt. The service reads the rank and score with HGET. This gives a direct lookup for one player instead of scanning the complete leaderboard. The response returns the player’s score and rank through the leaderboard API and API Gateway to the game client.

For POST /leaderboard/score, the leaderboard service updates the Redis ranking data using ZADD or ZINCRBY. It also updates the player data used by the fast lookup path. The diagram shows background workers handling bulk persistence, rank rebuilding when needed, and cleanup or TTL work. These workers help keep the hot leaderboard data useful while moving durable score information to Cassandra or MongoDB.

Cassandra or MongoDB is the durable score store in this design. Redis is the fast path for reads, while durable storage protects score data beyond the cache layer. The diagram also includes observability for logs, metrics, alerts, and tracing. These signals help detect slow reads, failed persistence, and worker problems. The APIs are stateless and can scale horizontally. The main trade-off is consistency timing. Fast Redis responses improve latency, but asynchronous persistence and rank rebuilding can temporarily lag behind the newest updates.

The benefit of this design is that common leaderboard reads stay fast. A Redis sorted set serves the top leaderboard, while a Redis hash gives direct access to one player’s score and rank. The diagram describes the player lookup as O(1). The API Gateway also protects the service with rate limiting, authentication, authorization, routing, and request validation. The downside is that Redis, background workers, and durable storage must stay coordinated. Asynchronous persistence improves the write path, but the durable store can briefly lag behind Redis. Rank rebuilding can also take time after many score changes. We accept this because leaderboard traffic needs very fast top-N and individual-player reads.

At a high level, I would put a moderation pipeline between submitted content and the final client response. Client Apps send text, images, or video through the API Gateway using HTTPS and JWT. The gateway checks identity, scopes, limits, and request shape. The Moderation Orchestrator Service loads safety policy, gets content features, calls the ML Inference Service, and creates the decision. Uncertain or high-risk cases use Human Review. The response returns as allow, block, or warn with a reason. The trade-off is stronger safety and auditability, but with more latency and operational complexity.

This question asks how we can check user content before deciding whether it is safe. The content may be text, an image, or a video. The system should quickly return a useful decision such as allow, block, or warn. It should also keep enough information to explain and audit that decision. The difficult part is combining machine learning, written safety rules, and human judgment. I would explain the design by following the same path shown in the diagram, from the client request through moderation, review, storage, monitoring, and model improvement.

• Which content types are most important: text, images, or video?
• Which unsafe categories and risk thresholds matter most?
• What latency is acceptable for the moderation response?
• When should an uncertain case require human review?

The request starts in Client Apps for web or mobile users. The client sends content through HTTPS with a JWT to the API Gateway. A JWT is a signed token that carries caller identity information. The gateway performs authentication, scope-based authorization, rate limiting, request validation, DDoS protection, and schema enforcement. If those checks succeed, it forwards the validated request to the Moderation Orchestrator Service.

The Moderation Orchestrator Service is the .NET and ASP.NET Core service coordinating the moderation flow. It asks the Policy & Rules Service for policies, taxonomies, risk thresholds, allow or block lists, and label definitions. Policy data returns to the orchestrator. The orchestrator also sends a feature request to the Feature Processing Service. That service produces text, image, and video features, embeddings, signals, and context. Those features return to the orchestrator for model evaluation.

The orchestrator sends an inference request to the ML Inference Service. That service contains text, image, video, multimodal, and risk-scoring models. It returns scores to the orchestrator. The orchestrator combines those scores with the safety rules and thresholds. It then generates the moderation decision and related reason information. This separation is important because a model score is only a signal. The written safety policy still helps determine the final action.

The diagram includes a Human Review Platform for uncertain or high-risk cases. The moderation path can send those cases for review. Reviewers can inspect the content and metadata, use reviewer tools, create a decision and annotation, and use escalation workflows when necessary. The review result then returns to the moderation path. This adds a human safety layer for cases where automatic scoring is not enough.

The Moderation Orchestrator Service sends its decision response back to the API Gateway. The internal response carries the moderation action, reasons, and scores. The gateway then sends the HTTPS JSON API response back to Client Apps. The user-facing result is allow, block, or warn with a reason. Request and response remain separate flows, so the response travels back through the same gateway boundary instead of coming from logging or storage components.

Decision and audit information is recorded across the supporting data and observability components. The Moderation Store keeps content metadata, decisions and scores, applied policies, review outcomes, and user actions. Content Storage keeps original content, thumbnails or frames, and derived artifacts. The Audit & Moderation Store keeps requests, responses, decisions, policy versions, reviewer actions, and system events as immutable logs. Metrics & Monitoring tracks latency, throughput, model performance, error rates, drift, and alerts. These systems support auditability and operations; they do not own the business response.

The Model Training Pipeline contains labeled-data ingestion, data validation and deduplication, model training, evaluation and fairness checks, and a versioned model registry. A trained, versioned model is then delivered to the ML Inference Service. The safety principles in the diagram emphasize defense in depth, privacy and data minimization, transparency, fairness, and continuous improvement. The benefit is safer and more explainable moderation. The downside is additional cost, latency, model governance, and operational work.

The benefit of this design is clear separation of responsibilities. The API Gateway protects the entry point. The Moderation Orchestrator Service owns the moderation workflow. Policy, feature processing, inference, review, storage, monitoring, and training remain separate. This makes the system easier to audit and lets expensive parts scale independently. The downside is more network calls and more services to operate. Human review improves difficult decisions, but it costs money and can add delay. Keeping model versions, policy versions, reviewer decisions, and audit records also adds operational work. The system accepts this complexity because unsafe-content decisions need more than one protection layer. Machine learning gives fast signals, rules enforce safety policy, and human review handles difficult cases.

At a high level, an API is a contract that lets one software system use another without knowing its internal implementation. In this design, mobile apps, web apps, partner integrations, and other services send HTTPS requests through a public API contract. The contract defines endpoints, HTTP methods, headers, schemas, errors, rate limits, and versioning. The API gateway then routes, validates, authenticates, authorizes, and monitors requests before internal services handle them. The trade-off is extra gateway and governance complexity in exchange for security, loose coupling, and a stable interface.

This question asks what an API is and why software systems use one. In simple words, an API is an agreed way for one program to ask another program for something. The consumer only needs to know what it may ask for and what answer it will receive. It does not need to know how the provider works inside. The diagram shows this clear boundary between consumers and the provider. It also shows how requests enter, how shared security checks happen, how internal services do the work, and how responses return.

• Should I explain only the API concept, or also describe the gateway and security responsibilities shown in the design?
• Should I focus on the public HTTP API model shown in the diagram?

I would start by saying that an API is a contract between a consumer and a provider. The consumer may be a mobile app, web app, partner integration, or another service. The provider publishes the interface and owns the implementation behind it. In this diagram, the public contract defines the base URL and endpoints, HTTP methods such as GET, POST, PUT, and DELETE, request headers such as authorization information, request and response schemas, the status-code and error model, rate limits, usage policies, versioning, and deprecation rules. Consumers depend on this contract instead of depending on the provider's internal code.

The request first moves from the consumer toward the provider over HTTPS. HTTPS uses TLS to protect the network connection. The request must follow the public contract, including the expected method, headers, and data format. The diagram shows JSON or XML schemas for requests and responses. The contract boundary defines what consumers may send and what behavior they can expect. This separation creates loose coupling. The provider can change its internal implementation while keeping the public contract stable for consumers.

After the request passes through the public contract, it reaches the API gateway, which is the provider's entry point. The gateway handles routing and request validation. It also performs authentication and authorization. Authentication checks who the caller is, while authorization checks what that caller is allowed to do. The diagram shows JWT or OAuth 2 for authentication and RBAC or scopes for authorization. The gateway also applies rate limiting, request or response transformation, and logging and metrics. These common controls are applied before the request reaches the business services.

Once the request passes the gateway checks, the gateway routes it to the appropriate internal service. The diagram shows User Service, Order Service, Inventory Service, and Payment Service as examples of provider-owned implementation. These services contain business logic and operations. They remain hidden behind the public API contract. Internal services can use the database for persistent storage, the message broker for asynchronous events and messaging, and external services for third-party integrations. The message broker is a supporting asynchronous path and is not the normal synchronous response path to the consumer.

After the provider finishes the requested work, the response returns to the requesting consumer through the same public contract. The response follows the published response schema, such as JSON or XML. This gives the consumer a predictable result without exposing how the provider produced it internally. The diagram also defines a status-code and error model. If request validation, authentication, authorization, or rate-limit checks fail, the gateway rejects the request instead of allowing it to continue to the business services. The diagram does not specify individual numeric HTTP status codes, so I would not invent them.

Finally, I would explain how the provider operates and evolves the API. Logging, metrics, tracing, alerts, monitoring, and analytics give visibility into API behavior. API documentation, shown as OpenAPI or Swagger, describes the developer contract. A developer portal helps consumers understand and use that contract. Versioning and deprecation rules let the provider evolve the API while giving consumers a controlled migration path. The benefit is a clear boundary, consistent security, and loose coupling. The downside is additional gateway, documentation, monitoring, and governance work. We accept that complexity because consumers get one stable and controlled interface.

The main design choice is to keep a stable API contract in front of changing internal services. The benefit is that mobile apps, web apps, partners, and other services can depend on one clear interface. HTTPS protects traffic. Authentication checks who the caller is, while authorization checks what that caller may do. Request validation and rate limiting protect the provider from invalid or excessive traffic. Versioning and deprecation make changes safer for consumers. The API gateway centralizes these shared rules, which keeps business services focused on their own work. The downside is that the gateway and governance layer add operational effort. Documentation, logging, metrics, tracing, alerts, monitoring, and analytics also require maintenance. We accept this because the design gives better consistency, security, visibility, and loose coupling between consumers and the provider.

At a high level, I would protect privacy by asking for clear user consent and requesting only the Facebook data the application really needs. The user authorizes access through OAuth 2.0. The .NET application then sends an HTTPS request with a bearer token and least-privilege scopes to the Meta API Gateway. Meta validates the token, app status, permissions, rate limits, and policies, then returns only permitted data. I would also secure tokens, minimize stored data, honor deletion and revocation, and audit access. The trade-off is more operational work for much lower privacy risk.

This question asks how an application can use Facebook information while respecting the person's privacy. The goal is simple. Ask before using data, collect only what is needed, protect it, and let the person stay in control. The difficult part is making sure every request stays inside the permissions the person granted. We also need to remove information when it is no longer needed. I would explain the design by following the diagram from user consent, through the .NET application and Meta systems, and back with only allowed data.

• Which Facebook data does this application actually need?
• Which permissions must the user grant?
• Does any requested permission require Meta App Review?
• How long does the application need to retain returned data?

I would start with the user because privacy begins with informed consent. The End User chooses to log in and authorize access using OAuth 2.0. The .NET application presents a consent screen that explains the requested scopes. A scope is simply a permission for a particular kind of access. The application should request only the scopes needed for the current feature. The diagram also keeps control with the user afterward. The user can manage permissions, revoke application access, delete data, and control related settings.

Inside the .NET application, I would secure access tokens and request only what the feature needs. The diagram shows secure token storage, short-lived tokens, and token rotation or refresh. It also shows least-privilege scopes and just-in-time requests. This reduces unnecessary access. The application collects minimum data, protects data in transit with TLS, encrypts stored data at rest, and limits internal access with RBAC. RBAC means only approved roles can access protected information.

The main request moves from the .NET application to the Meta API Gateway. The diagram labels this contract as HTTPS plus a bearer token with least-privilege scopes. HTTPS protects the request while it travels. The bearer token represents authorized access. The application should not request unrelated fields merely because the API could expose them. Keeping the request narrow makes the technical behavior match the purpose explained to the user.

The Meta API Gateway validates the token, checks the app status, enforces rate limits, and enforces platform policies. After those checks, authorized data access moves from the gateway into Meta systems. The Permissions and Policy Engine validates permissions, applies platform policy checks, and handles App Review requirements. These controls belong to Meta rather than the .NET application. The diagram does not show a separate error response or fallback path. If these authorization checks do not allow the request, the authorized data-access step should not proceed.

Meta systems expose scoped user data rather than unrestricted information. The diagram shows field-level filtering and states that friends' data is not available without permission. Filtered data moves from Meta systems back to the Meta API Gateway within the permission boundaries. The gateway then returns the API response to the .NET application. That response contains only permitted data. This keeps the response path aligned with the user's consent and the permissions enforced by Meta.

After receiving data, the .NET application should retain only what it needs. The Data Lifecycle control says to keep data only as needed, delete it when it is no longer necessary, and respect user deletion. Logging and Monitoring records API access, helps detect abuse, and raises anomaly alerts. Compliance and Protection covers platform policies, privacy impact assessments, and regular reviews. These are supporting controls connected to the gateway. They are not part of the main synchronous API response path.

The benefit of this design is smaller privacy exposure and stronger user control. The downside is extra work. Short-lived tokens require rotation or refresh handling. Least-privilege permissions can require another consent step when a new feature needs more data. Logging, deletion handling, access control, and compliance reviews also increase operational effort. I would accept that cost because the design keeps data access tied to consent, purpose, and Meta's permission boundaries.

The main design choice is to expose and store less data instead of taking everything the API could provide. The benefit is lower privacy risk because requests stay inside the user's granted permissions. HTTPS protects data while it travels. Secure token storage and short-lived tokens reduce the risk from token misuse, but token rotation and refresh add work. Data minimization and deletion reduce long-term exposure, but the application needs good lifecycle handling. Meta also validates tokens, app status, permissions, rate limits, and platform policies before allowing access. Logging and compliance checks improve accountability, but they add operational cost. Least-privilege permissions can limit features or require new consent later. We accept these costs because user control and narrow permission boundaries are more important than convenience.