Design searchable status & geolocation services

Last updated: Mar 29, 2026

Quick Overview

Design searchable status & geolocation services evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

|Home/System Design/Meta

Design searchable status & geolocation services

Meta

Jul 29, 2025, 8:05 AM

hardSoftware EngineerOnsiteSystem Design

7

0

Design searchable status & geolocation services

System Design: Searchable Short-Form Status Updates with Nearby Search

Context

Design a microblogging service where users post short text updates (think: "statuses"). Users must be able to search:

Full-text across historical posts (e.g., keyword search, filters by time/language).
Geolocation-based "nearby" results (e.g., find posts within a radius from a location, sorted by distance and/or recency).

Assume internet-scale usage with high read and write throughput and global users.

Requirements

Functional
- Users can create, edit, and delete short text posts (e.g., up to 280 characters), optionally with a location (lat, lon).
- Public search: keyword queries across all public posts; filters for time range, language, and presence of geolocation.
- Nearby search: given (lat, lon) and radius, return relevant posts near that location, supporting sort by distance and/or recency.
- Respect privacy/visibility (e.g., public vs restricted); search should only show authorized content.
Non-Functional
- Low latency: p50 < 200 ms, p95 < 500 ms for typical searches; writes < 150 ms.
- Freshness: new posts searchable within seconds (near real-time indexing).
- High availability and horizontal scalability; multi-region read latency optimization.
- Cost-effective historical search (tiered storage for older data).

What to Design

High-level architecture (write path, index pipeline, search path).
Data model and storage choices for posts and indexes.
Full-text indexing and query processing (tokenization, ranking, pagination).
Geolocation indexing and query execution for nearby search.
Scaling/sharding strategies, caching, and consistency/freshness trade-offs.
Handling edits/deletes, privacy filtering, and operational considerations (monitoring, reindexing).

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Meta•More Software Engineer•Meta Software Engineer•Meta System Design•Software Engineer System Design

Your design canvas — auto-saved