面接のフレームワーク — 4ステップで攻略する

# Railsモデルで要件を構造化して考える例
# 確認した要件をコードで表現すると思考が整理される
 
# 機能要件 → モデルの責務に対応する
class Tweet < ApplicationRecord
  belongs_to :user
  validates :content, presence: true, length: { maximum: 280 }
  # 画像は今回スコープ外 → has_many :media_attachments は不要
end
 
class Follow < ApplicationRecord
  belongs_to :follower, class_name: 'User'
  belongs_to :followed, class_name: 'User'
  validates :follower_id, uniqueness: { scope: :followed_id }
end
 
# 非機能要件 → インフラの制約に対応する
# DAU 1億、読み100:書き1 → キャッシュ重視の設計が必要
# レイテンシ500ms → データベース直接アクセスは避ける
# 結果整合性OK → タイムラインに多少の遅延は許容できる

# 面接前に暗記しておく数字（Rubyの定数として整理）
module ScaleConstants
  # 時間
  SECONDS_PER_DAY   = 86_400    # ≈ 10万秒と覚える
  SECONDS_PER_MONTH = 2_592_000  # ≈ 300万秒
  SECONDS_PER_YEAR  = 31_536_000 # ≈ 3000万秒
 
  # データサイズの目安
  TWEET_BYTES        = 300       # テキストツイート1件
  USER_RECORD_BYTES  = 1_000     # ユーザーレコード1件
  PHOTO_BYTES        = 1_000_000 # 写真1枚（圧縮後）
 
  # レイテンシ（Latency Numbers Every Programmer Should Know）
  L1_CACHE_NS      = 1    # L1キャッシュ参照: 1ns
  MEMORY_ACCESS_NS = 100  # メモリアクセス: 100ns
  SSD_READ_US      = 100  # SSD読み取り: 100μs
  HDD_READ_MS      = 10   # HDD読み取り: 10ms
  NETWORK_ROUND_MS = 150  # ネットワーク往復: 150ms（大陸間）
end

// Golangで概算計算を実装する例（面接中のメモとして使える）
package main
 
import "fmt"
 
type TwitterScale struct {
	DAU            int64
	ReadWriteRatio int64
	TweetSizeBytes int64
	PeakMultiplier int64
}
 
func (s *TwitterScale) WriteQPS() int64 {
	tweetsPerDay := s.DAU * 1 // 1ユーザー1日1ツイート
	return tweetsPerDay / 86400
}
 
func (s *TwitterScale) ReadQPS() int64 {
	return s.WriteQPS() * s.ReadWriteRatio
}
 
func (s *TwitterScale) StoragePerYear() int64 {
	tweetsPerDay := s.DAU * 1
	return tweetsPerDay * s.TweetSizeBytes * 365
}
 
func main() {
	scale := &TwitterScale{
		DAU:            100_000_000,
		ReadWriteRatio: 100,
		TweetSizeBytes: 300,
		PeakMultiplier: 5,
	}
	fmt.Printf("Write QPS: %d/sec\n", scale.WriteQPS())
	// ~1,157/sec
	fmt.Printf("Read QPS: %d/sec\n", scale.ReadQPS())
	// ~115,700/sec
	fmt.Printf("Storage/Year: %.0f GB\n",
		float64(scale.StoragePerYear())/1_000_000_000)
	// ~10.9 TB
}

# Tweet API: ツイートの投稿と取得
class TweetsController < ApplicationController
  def create
    tweet = current_user.tweets.create!(tweet_params)
    # Kafkaにイベントを送信して非同期でファンアウト
    TweetPublishedEvent.publish(tweet_id: tweet.id, user_id: tweet.user_id)
    render json: tweet, status: :created
  end
 
  private
 
  def tweet_params
    params.require(:tweet).permit(:content)
  end
end
 
# Timeline API: Redisから事前構築済みタイムラインを返す
class TimelinesController < ApplicationController
  def show
    # カーソルベースのページネーションで一貫性を保つ
    tweet_ids = redis.lrange(
      "timeline:#{current_user.id}",
      0,
      (params[:limit] || 20).to_i - 1
    )
    tweets = Tweet.where(id: tweet_ids).index_by(&:id)
    render json: tweet_ids.map { |id| tweets[id.to_i] }.compact
  end
end

// Golang: Worker（Kafkaコンシューマー）でのファンアウト実装例
package worker
 
import (
	"context"
	"fmt"
 
	"github.com/segmentio/kafka-go"
)
 
type FanoutWorker struct {
	reader    *kafka.Reader
	redisPool RedisPool
	db        Database
}
 
func (w *FanoutWorker) Run(ctx context.Context) {
	for {
		msg, err := w.reader.ReadMessage(ctx)
		if err != nil {
			continue
		}
		tweetID := parseTweetID(msg.Value)
		w.fanout(ctx, tweetID)
	}
}
 
func (w *FanoutWorker) fanout(ctx context.Context, tweetID int64) {
	// フォロワー一覧を取得してそれぞれのタイムラインに追加
	followers := w.db.GetFollowers(ctx, tweetID)
	for _, followerID := range followers {
		key := fmt.Sprintf("timeline:%d", followerID)
		// LPUSHで先頭に追加、LTRIMで上限管理
		w.redisPool.LPush(ctx, key, tweetID)
		w.redisPool.LTrim(ctx, key, 0, 999) // タイムラインは1000件まで保持
	}
}

# Rails routesとして表現する
Rails.application.routes.draw do
  namespace :v1 do
    resources :tweets, only: [:create, :show, :destroy]
    resource :timeline, only: [:show]
  end
end
 
# カーソルベースのページネーション実装
class V1::TimelineController < ApplicationController
  def show
    cursor_tweet_id = params[:cursor]&.to_i
    limit = (params[:limit] || 20).to_i.clamp(1, 100)
 
    tweet_ids = if cursor_tweet_id
      # カーソル以降のツイートIDをRedisから取得
      all_ids = redis.lrange("timeline:#{current_user.id}", 0, -1)
      start_idx = all_ids.index(cursor_tweet_id.to_s) || 0
      all_ids[start_idx + 1, limit]
    else
      redis.lrange("timeline:#{current_user.id}", 0, limit - 1)
    end
 
    tweets = Tweet.where(id: tweet_ids).order(created_at: :desc)
    render json: {
      tweets: tweets,
      next_cursor: tweets.last&.id
    }
  end
end

# ハイブリッド方式のタイムライン取得
class HybridTimelineService
  CELEBRITY_THRESHOLD = 1_000_000
 
  def get_home_timeline(user_id, limit: 20)
    # 1. Redisから通常ユーザーのプリビルドタイムラインを取得
    cached_ids = redis.lrange("timeline:#{user_id}", 0, limit * 2 - 1)
 
    # 2. フォロー中のセレブリティのツイートをDBから直接取得
    celebrity_followings = Follow
      .where(follower_id: user_id)
      .joins(:followed)
      .where("users.followers_count > ?", CELEBRITY_THRESHOLD)
      .pluck(:followed_id)
 
    celebrity_tweets = Tweet
      .where(user_id: celebrity_followings)
      .order(created_at: :desc)
      .limit(limit)
 
    # 3. マージしてソート
    cached_tweets = Tweet.where(id: cached_ids)
    (cached_tweets + celebrity_tweets)
      .uniq(&:id)
      .sort_by { |t| -t.created_at.to_i }
      .first(limit)
  end
end

# 練習ログを記録するモデル（実際に記録をつけると上達が早い）
class MockInterviewSession
  SCORING_CRITERIA = {
    requirements_clarity: "要件確認でスコープを絞れたか",
    scale_estimation:     "数字で根拠を示せたか",
    component_design:     "コンポーネントの役割を説明できたか",
    tradeoff_discussion:  "トレードオフを語れたか",
    time_management:      "各ステップの時間を守れたか"
  }.freeze
 
  attr_reader :problem, :scores
 
  def initialize(problem)
    @problem = problem
    @scores  = SCORING_CRITERIA.keys.each_with_object({}) { |k, h| h[k] = 0 }
  end
 
  def evaluate(criterion, score_0_to_5)
    @scores[criterion] = score_0_to_5
  end
 
  def weakest_area
    scores.min_by { |_, v| v }.first
  end
 
  def report
    SCORING_CRITERIA.each do |key, label|
      puts "#{label}: #{scores[key]}/5"
    end
    puts "最も改善が必要な領域: #{SCORING_CRITERIA[weakest_area]}"
  end
end

# 面接の進め方（擬似コード）
def system_design_interview(problem)
  # Step 1: 要件確認（5分）
  # ファンネル形式で機能→スコープ外→非機能の順に確認
  requirements = clarify_requirements(problem)
  confirm_understanding(requirements) # 「この理解で進めていいですか？」
 
  # Step 2: 規模概算（5分）
  # 声に出しながら計算。桁の精度でいい
  scale = estimate_scale(requirements)
  # QPS、ストレージ、帯域の3点を押さえる
 
  # Step 3: 高レベル設計（20分）
  # 4ボックス（クライアント→LB→サービス→DB）から始める
  design = high_level_design(requirements, scale)
  # コンポーネントを追加するたびに「なぜ」を説明する
 
  # Step 4: 深掘り（10分）
  # 面接官の関心を聞いてから、トレードオフを語る
  deep_dive = refine_with_tradeoffs(design, interviewer_concerns)
  # 「〜という懸念はもっともです。A vs Bのトレードオフとして……」
end