Amazon Java Developer Interview Questions & Answers

At a high level, I would design a small Java file-search API that separates directory traversal from filtering. The client calls FileSearchAPI with a root path and Filter criteria. SearchService coordinates the work, while FileSystemWalker traverses the Unix file system and returns file entries plus metadata. ExtensionFilter, NameFilter, and SizeFilter handle individual rules, and AndFilter, OrFilter, and NotFilter combine them. Matching entries become a List<FileEntry> and return through FileSearchAPI. The trade-off is more small classes, but new constraints stay easy to add.

This question asks us to build a simple way to find files under a chosen folder. The caller may want files with a certain ending, name, or size. The hard part is keeping the design easy to change when new search rules appear. We also need to walk folders safely and return only matching files. The diagram solves this by separating the public API, search coordination, folder walking, file information, filters, filter combinations, and result collection. I would explain the design in that same order.

• Should searches always include subdirectories, or should recursion be configurable?
• What should happen when a directory cannot be read because of permissions?
• What symlink behavior and maximum traversal depth should we use?

I would begin with FileSearchAPI because it is the public entry point. The client calls search(rootPath, criteria). The diagram shows example criteria such as extension=.java, a name containing "Service", and size > 10 KB. The public contract returns List<FileEntry>. This keeps callers independent from the internal traversal and filtering classes.

FileSearchAPI passes the work to SearchService. SearchService orchestrates traversal and filtering. It asks FileSystemWalker to traverse the requested root path. It also applies the supplied Filter criteria and collects matching entries. This keeps the high-level search flow in one place while lower-level responsibilities stay separate.

SearchService calls FileSystemWalker with traverse(rootPath). FileSystemWalker recursively walks the Unix directory tree and reads directories and files from the Unix File System. The file system returns file entries plus metadata. The walker owns traversal concerns such as recursion, maximum depth, permission-denied handling, and symlink policy. These rules decide which paths can be visited before filtering happens.

The design represents each discovered item as FileEntry or FileMetadata. The diagram shows path, name, extension, size, isDirectory, and optional lastModified. Filters read these values instead of accessing the file system themselves. That makes the matching logic easier to test and keeps file-system access separate from search rules.

The Filter interface exposes boolean matches(FileEntry file). ExtensionFilter checks the extension. NameFilter checks whether the file name contains a value or matches a pattern. SizeFilter checks file size. SearchService applies the criteria to FileEntry metadata. Because all rules share one interface, SearchService does not need a growing chain of special-case conditionals.

For multiple conditions, I would build a Filter tree. AndFilter matches only when all child filters match. OrFilter matches when any child matches. NotFilter negates one child filter. This supports combinations such as extension is .java AND name contains Service AND size is above 10 KB. The key maintainability choice is the Open/Closed Principle: a new constraint is added by implementing Filter rather than rewriting the stable search orchestration.

When entries satisfy the composed criteria, SearchService collects them in SearchResult, shown as List<FileEntry>. SearchResult holds the matched file entries and returns the collected list upward to FileSearchAPI. FileSearchAPI then returns the List<FileEntry> result to the client. The main trade-off is extra small classes and a filter tree. In return, traversal, metadata, filtering, and result handling remain easier to change independently.

The main design choice is separating directory walking from filter rules. The benefit is that FileSystemWalker can focus on recursion, depth limits, permission failures, and symlink policy. Filter classes focus only on matching FileEntry metadata. Composite filters add more objects, but they make AND, OR, and NOT combinations easy to build. The Open/Closed approach also means a new constraint usually needs a new Filter implementation instead of changes to SearchService. The downside is more classes than a single method with many if statements. Search time can still grow with the number of files and directories visited. We accept that cost because the design stays understandable, testable, and maintainable as search requirements grow.

At a high level, I would expose one search API that chooses the best underlying search service instead of calling every service. The client sends HTTPS GET /search?q=keyword&limit=10. The request is validated and normalized, then checked in the Result Cache. On a cache miss, the Query Router uses routing rules, service health, and latency to choose one provider. A second provider is used only for an empty result, timeout, or low confidence. This reduces fan-out and latency, but it makes accurate routing decisions more important.

We need one simple way for a caller to search across several different search systems. The caller should not decide whether a keyword belongs to product, document, or web search. The service should make that choice. It should also avoid asking every search system for every request because that creates extra work and longer waits. Repeated searches should reuse saved results when possible. If the first chosen service cannot give a useful answer, one backup may be tried. The explanation below follows the exact cache, routing, provider, fallback, response, and logging design in the diagram.

• How should we decide which search service is best for a keyword?
• How fresh must results in the Result Cache be?
• When should an empty result or low confidence trigger the secondary service?

I would begin with one public entry point. The Client / Caller sends HTTPS GET /search?q=keyword&limit=10 to the Search API. This hides the External Search Services from the caller. The caller does not need to know whether Product Search Service, Document Search Service, or Web Search Service should handle the keyword. The Search API later returns the aggregated search response. It also sends an asynchronous request log to Query Logs + Metrics. That logging flow is separate from the business response path.

The Search API forwards the request to Request Validation + Query Normalization. This component checks the search input and puts the query into a consistent form. The flow then performs a cache lookup in the Result Cache. If matching cached results exist, they can go directly toward Response Formatter. This lets repeat queries avoid provider calls. If the cache does not contain the result, the cache-miss path continues to Query Router.

On a cache miss, Query Router decides which provider should receive the query. It consults Routing Rules + Service Metadata. The router loads routing rules together with service health and latency information. Routing Rules + Service Metadata provides the best target service back to Query Router. The key decision is to choose one best service first. The design does not fan out every request to all search services. Query Router then sends the selected provider toward Provider Adapters. This reduces unnecessary calls and usually lowers latency.

Provider Adapters handle communication with the chosen External Search Service. The primary search request is sent to the selected provider, shown as Product Search Service in the main path. Its search response is consumed by Provider Adapters. The design also has a limited fallback path. A secondary request is made only when needed, such as when the first call times out, returns an empty result, or has low confidence. The diagram shows Document Search Service as the secondary example. Its fallback response returns to Provider Adapters. Web Search Service is also shown as another underlying search option. The important rule is that the service does not call every provider by default.

Provider Adapters send the normalized provider result to Response Formatter. Response Formatter creates the common JSON response shown in the diagram: {results, source, traceId}. It also stores the result in Result Cache with a TTL. TTL means the cached value expires after a limited amount of time. The JSON response then returns to Search API. Search API sends the aggregated search response back to Client / Caller. A cache hit follows the shorter path and avoids Query Router, Provider Adapters, and the external provider call.

Query Logs + Metrics receives asynchronous operational information. Search API sends the request log there. The routing path also records routing and latency metrics. These measurements help show which services are selected and how providers are performing. They support operating and tuning the routing behavior without becoming part of the synchronous response path. The main trade-off is added routing logic. A simple fan-out design is easier to reason about, but it creates more service calls. This design accepts more routing complexity to reduce provider traffic and latency.

The main choice is to call one search service first instead of calling all of them. The benefit is fewer service calls, lower latency, and less load on the External Search Services. The downside is that Query Router must choose well using routing rules, health, and latency. Result Cache also saves work because repeated queries can avoid provider calls. Its downside is freshness, so results use a TTL. The fallback path improves reliability when the first provider times out, returns an empty result, or has low confidence. The downside is that fallback adds another call and makes that request slower. We accept that extra cost only when the primary provider does not produce a useful result.

At a high level, I would make product reviews a small resource-focused API. The client signs in through the Identity Service and sends a JWT with each protected request. Creating a review uses POST /v1/products/{productId}/reviews, while listing reviews uses GET on the same product resource. The API derives the reviewer identity from JWT.sub instead of trusting a userId from the body. It checks the product, validates the request, and stores the review. A unique product-and-user rule prevents duplicates. The trade-off is extra validation and database coordination for stronger correctness.

This question asks us to design a simple way for customers to create and read product reviews. We need clear addresses for each action and clear rules for what information the customer sends. We also need to stop the same customer from creating duplicate reviews for one product. Another important goal is making sure customers cannot pretend to be another user. I will follow the diagram from sign-in, through review creation and reading, to database storage, errors, and logging.

• Can one user have only one active review for each product?
• Should users be allowed to edit and delete their own reviews?
• Do we need average rating and total review count in the list response?

I would first establish who the user is. The Web / Mobile Client signs in through the Identity Service using OAuth2. The Identity Service returns a JWT access token. A JWT is a signed token containing trusted identity information. The Product Reviews API sits inside the Java application boundary. It validates the JWT before using the request. The reviewer identity comes from JWT.sub, which identifies the authenticated user. The client must not send or choose its own userId.

For creation, the client sends POST /v1/products/{productId}/reviews. The request includes Authorization: Bearer <JWT> and Idempotency-Key: <uuid>. The body contains only review data: rating, title, and body. The diagram's example uses rating 5, title Great product, and body Fast delivery and durable. The Product Reviews API performs JWT validation and request validation. It never trusts a user identity from the JSON body.

The Product Reviews API then asks the Product Catalog Service to validate productId. The Product Catalog Service responds that the product exists or reports 404 not found. This prevents a review from being attached to a product that does not exist.

The API applies its duplicate review guard before storing the review. The Reviews DB also enforces UNIQUE(product_id, user_id). This protects the rule shown in the diagram that a user should not create duplicate reviews for the same product. The Idempotency-Key handles a related case. It lets a client safely retry the same POST request without intentionally creating another review.

The API inserts the review using userId = JWT.sub. The Reviews DB stores fields including review_id, product_id, user_id, rating, title, body, created_at, updated_at, and status. The database returns either a stored result or a unique-constraint violation. A successful create returns 201 Created with reviewId, productId, rating, title, body, and createdAt. A duplicate returns 409 Conflict with code: DUPLICATE_REVIEW and existingReviewId.

For reading, the client sends GET /v1/products/{productId}/reviews?page=1&size=10&sort=recent. The Product Reviews API asks the Reviews DB for reviews and aggregates. The database returns rows, average rating, and total count. The API then returns 200 OK with productId, averageRating, totalCount, and reviews.

The query parameters provide pagination and recent-first sorting. This avoids returning every review in one response and keeps the contract clear for the client.

The diagram also shows PATCH /v1/reviews/{reviewId} and DELETE /v1/reviews/{reviewId}. These operations are allowed only for the review owner or an admin. Authentication and authorization are separate checks. JWT validation proves who the caller is. The ownership check decides whether that caller may change or delete the selected review.

Missing or invalid authentication can return 401. An authenticated caller who is not allowed can receive 403. The API continues to derive identity from the JWT instead of trusting a client-supplied user identifier.

The Product Reviews API sends structured logs and metrics to Audit / Metrics. This is an observability path and is separate from the business response path.

The main trade-off is extra work on each write. JWT validation, request validation, product validation, duplicate protection, and database constraints add processing and dependencies. The benefit is stronger identity handling and more reliable review data. The design keeps the API contract simple while placing final duplicate enforcement in the Reviews DB, where concurrent writes cannot bypass the unique constraint.

The benefit of this design is that each rule has a clear owner. The Identity Service gives the client a JWT, while the Product Reviews API validates it and uses JWT.sub as the reviewer identity. This is safer than accepting userId from the request body. The database unique rule protects against competing requests creating reviews for the same product and user. The Idempotency-Key also makes POST retries safer. The downside is that creating a review needs several checks, including a call to the Product Catalog Service and a write to the Reviews DB. Those steps add latency and create more failure points. We accept this because product validation and duplicate prevention improve data correctness. Pagination also keeps large review lists manageable.

At a high level, I would expose one capture API that accepts an address, its country, and its uniqueness scope. The request goes through an API Edge using HTTPS, JWT, and rate limits, then reaches POST /v1/addresses:capture. The Java service validates the payload, performs country-aware normalization, resolves the scope, builds a normalized unique key, and checks the Address Store. It returns an existing address or creates a canonical one. The unique index and optional idempotency key reduce duplicates. The trade-off is the extra complexity of worldwide normalization rules.

The goal is to let clients send addresses from many countries and store each address only once inside the requested scope. The difficult part is that addresses are written differently around the world. We also need a clear rule for deciding when two addresses should count as the same. I would keep the original address, create a standard version, and compare that version inside the requested scope. The diagram shows the complete path from the client, through validation and normalization, to storage and the final response.

• What scopes do we need to support, such as GLOBAL, TENANT, or ACCOUNT?
• Can clients send either free-form addresses or structured address fields?
• Is postal or geographic verification required, or only optional enrichment?
• Should an already captured address return its existing identifier instead of creating another record?

I would expose POST /v1/addresses:capture for address capture. The client sends a capture request through the API Edge. The request can contain rawAddress or structured address fields, plus countryCode, scopeType, scopeId, and an optional idempotencyKey.

The API Edge handles HTTPS, JWT, and rate limits. It then forwards the API request to the Java Unique Address API. The optional idempotency key can prevent duplicate inserts when a client retries the same request.

The Java API first performs Payload Validation. It checks the required fields and validates countryCode, scopeType, and scopeId. It also accepts the optional idempotencyKey shown in the request.

An invalid payload returns 400. This stops bad input before normalization or storage work begins.

Next, the Normalization Engine creates a canonical, or standard, form of the address. It can parse free-form or structured input. It trims whitespace, normalizes casing, expands standard abbreviations, and standardizes country, state, and postal codes. It also supports Unicode and transliteration when needed.

Worldwide capture cannot rely on one universal address string format. The engine therefore uses the Country Rules / Reference Catalog for ISO codes, region aliases, and postal rules.

Postal / Geo Validation is optional. It can verify or enrich the normalized address. If the service cannot normalize or verify the address when required, the diagram shows a 422 response.

The Scope Resolver decides the uniqueness boundary. The diagram shows example scopes of GLOBAL, TENANT, and ACCOUNT.

This matters because the same canonical address can be treated differently under different scopes. The selected scopeType and scopeId therefore become part of the uniqueness key.

The Unique Key + Match Check builds a deterministic key using scopeType + scopeId + normalizedHash. The normalized hash represents the canonical address components.

The service performs the lookup or insert against the Address Store. The store keeps the raw submitted address, canonical normalized fields, and scope metadata. It also enforces a unique index on (scopeType, scopeId, normalizedHash).

If a matching record exists, the service returns the existing addressId. If there is no match, it creates the canonical address. The storage-level unique index is the final protection against duplicate scoped records.

The response contains addressId, canonicalAddress, scope, and status=new|existing. A newly created address returns 201 Created. An address already captured in the requested scope returns 200 OK.

The response returns from the Java API through the API Edge and then back to the client. Separately, the Java API sends an AddressCaptured or AddressReused event to the Audit Event Log. The audit log records the event but is not part of the business response path.

The main trade-off is normalization complexity. Country-specific rules and optional verification improve consistency and duplicate detection, but they require more reference data and maintenance.

The benefit of this design is that one API can support many countries without pretending every country uses the same address format. Country-aware normalization makes duplicate checks more reliable. Scope gives flexible uniqueness because an address can be unique globally or inside a tenant or account. The storage unique index is important because it gives one final rule for (scopeType, scopeId, normalizedHash). The optional idempotency key also helps with repeated client requests. The downside is added complexity. Country rules can change, normalization is not always perfect, and optional postal or geographic verification adds another dependency. Keeping both raw and canonical forms uses more storage, but it preserves the original input. Rate limiting at the API Edge helps protect the service from excessive traffic.