Train Harder Interview Preparation

When choosing a database, evaluate the following five criteria to determine the best fit for the architecture:

1. Read/Write Ratio: Is the workload write-heavy or read-heavy?
2. Scaling Strategy: Is horizontal scaling (adding more machines) or vertical scaling (adding more power to one machine) required?
3. CAP Theorem Trade-offs: Which of the three CAP properties (Consistency, Availability, Partition Tolerance) is most critical for the specific use case?
4. Developer Familiarity: What technologies does the company already use and which query languages are the developers proficient in?
5. Data Constraints: Is the dataset small enough for in-memory storage? What replication needs exist? Is a graph structure required?

Virtual memory allows the system to execute processes that are not entirely loaded into RAM by utilizing disk space. A Translation Lookaside Buffer (TLB) is used to accelerate the translation of virtual addresses to physical addresses.

Advantages:

• Enables more efficient memory usage.
• Supports dynamic linking.
• Facilitates code and data sharing between processes.

Disadvantages:

• Increased system complexity.
• Requirement to handle page interrupts (page faults) when requested data is not in RAM and must be fetched from disk.

A distributed Lock System (similar to Google's Chubby) is designed to manage resource locking across a network. It relies on a consensus algorithm, specifically Paxos, to ensure consistency and availability. The system must support the following core operations:

• Lock Request: Requesting exclusive access to a resource.
• Release Request: Relinquishing the lock on a resource.
• Renew Locktime Request: Extending the lease/timeout of a held lock to prevent premature expiration.

The system must support core social media interactions while prioritizing read performance and availability.

Functional Requirements:

• Creating tweets
• Viewing and generating a user timeline
• Following other users
• Interacting with tweets (e.g., liking)

Non-Functional Requirements:

• Optimize for read-heavy workloads
• Handle 'influencer' accounts (users with massive follower counts)
• Ensure high availability
• Maintain low latency for timeline generation

When designing a Twitter-like system, prioritize the following architectural patterns to handle scale and latency:

• Read/Write Ratio: The system is read-heavy; optimize for read performance.
• Consistency: Eventual consistency is acceptable for most operations.
• Latency Reduction: Use sharding, caching, CDNs, and pre-generated newsfeeds to minimize latency.
• Caching Strategy: Store the most popular tweets in cache. Use a processing job (e.g., Spark) to update follower feed caches when a new tweet is created, though high-profile users (celebrities) may require a different update strategy to avoid write amplification.
• Data Modeling: Consider using a Graph Database for relationship management and transitioning from batch processing to streaming (e.g., using Sparrow) for real-time updates.

The core functional requirements for a DoorDash-like system include:

1. Ability for users to place orders.
2. Matching orders with nearby delivery drivers (dashers).
3. Real-time tracking of both the driver's and the user's locations.