Design a Listing Connectivity Ingestion Service
Scenario
Design a Connectivity Service that enables external service providers (partners) to create or update listings on your company's platform. Your service will receive listing-creation requests from partners and must forward this data to an internal downstream system, the Validation / Domain Service, which is owned by another team. This downstream service is responsible for business validation and domain processing. After the internal validation process, your service must communicate the outcome back to the originating partner.
This interview requires a very detailed REST API specification, including endpoints, request/response payloads, headers, authentication mechanisms, and idempotency strategies. Additionally, a clear end-to-end flow diagram illustrating the system's operation is expected.
Requirements
Functional Requirements
- Accept listing creation and update requests from external partners.
- Perform basic edge validation on incoming requests (e.g., schema validation, authentication, size limits).
- Forward the validated request data to the internal Validation/Domain Service for business logic processing.
- Provide a clear outcome to the partner, indicating one of the following states:
- Listing accepted/created.
- Listing rejected with specific validation errors.
- Listing still processing (if the operation is asynchronous).
- Support safe retries from partners, ensuring that duplicate listings are not created.
API / Protocol Expectations
- The API must use HTTP with JSON payloads.
- The design must specify:
- Required HTTP headers (e.g.,
Content-Type, tracing/correlation IDs). - The chosen authentication and authorization mechanism.
- The strategy for ensuring idempotency.
- All possible HTTP status codes that can be returned and the conditions under which each applies.
- Required HTTP headers (e.g.,
Non-Functional Requirements
- The service must be scalable to handle high request volumes from multiple partners.
- It must be resilient to partner retries and tolerant of outages or high latency from the downstream Validation/Domain Service.
- The system must provide comprehensive observability (metrics, logs, tracing) and auditability capabilities.
Deliverables
- A proposed API design, including endpoints, example request/response payloads, and required headers.
- A sequence or flow description (a textual flow diagram is acceptable).
- Notes detailing considerations for scaling, reliability, and key edge cases.
AI interview prep
Core dilemma
Balancing the need for immediate, clear feedback to external partners with the inherent unreliability and potential latency of an internal, downstream validation service, all while ensuring high scalability, idempotency, and resilience.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Design a Listing Connectivity Ingestion Service
Scenario
Design a Connectivity Service that enables external service providers (partners) to create or update listings on your company's platform. Your service will receive listing-creation requests from partners and must forward this data to an internal downstream system, the Validation / Domain Service, which is owned by another team. This downstream service is responsible for business validation and domain processing. After the internal validation process, your service must communicate the outcome back to the originating partner.
This interview requires a very detailed REST API specification, including endpoints, request/response payloads, headers, authentication mechanisms, and idempotency strategies. Additionally, a clear end-to-end flow diagram illustrating the system's operation is expected.
Requirements
Functional Requirements
- Accept listing creation and update requests from external partners.
- Perform basic edge validation on incoming requests (e.g., schema validation, authentication, size limits).
- Forward the validated request data to the internal Validation/Domain Service for business logic processing.
- Provide a clear outcome to the partner, indicating one of the following states:
- Listing accepted/created.
- Listing rejected with specific validation errors.
- Listing still processing (if the operation is asynchronous).
- Support safe retries from partners, ensuring that duplicate listings are not created.
API / Protocol Expectations
- The API must use HTTP with JSON payloads.
- The design must specify:
- Required HTTP headers (e.g.,
Content-Type, tracing/correlation IDs). - The chosen authentication and authorization mechanism.
- The strategy for ensuring idempotency.
- All possible HTTP status codes that can be returned and the conditions under which each applies.
- Required HTTP headers (e.g.,
Non-Functional Requirements
- The service must be scalable to handle high request volumes from multiple partners.
- It must be resilient to partner retries and tolerant of outages or high latency from the downstream Validation/Domain Service.
- The system must provide comprehensive observability (metrics, logs, tracing) and auditability capabilities.
Deliverables
- A proposed API design, including endpoints, example request/response payloads, and required headers.
- A sequence or flow description (a textual flow diagram is acceptable).
- Notes detailing considerations for scaling, reliability, and key edge cases.