نوشته های Akhtar Sabzi

food

Akhtar Sabzi — Mon, 20 Jul 2026 23:23:16 +0330

Food Ordering System Design (High-Level)این طراحی برای یک سیستم مشابه Uber Eats، DoorDash یا SnappFood و در سطح مصاحبه Senior Java Developer / Software Architect تهیه شده است.1. RequirementsFunctional RequirementsUser Registration/LoginRestaurant ManagementMenu ManagementBrowse RestaurantsSearch FoodShopping CartPlace OrderPaymentRestaurant Accept/Reject OrderDelivery AssignmentDriver TrackingOrder StatusNotificationRating & ReviewNon Functional RequirementsHigh AvailabilityLow LatencyScalabilityFault ToleranceData ConsistencySecurityReal-time TrackingHorizontal Scaling2. Capacity EstimationAssume20 Million Users 2 Million Daily Active Users 500K Orders/Day Peak 500 Orders/sec Average 50 Orders/sec 3. High-Level Architecture +----------------------+ | Mobile/Web Client | +----------+-----------+ | HTTPS / REST | +------------v-------------+ | API Gateway / LoadBalancer| +------------+-------------+ | +-------------+-------------+-------------+--------------+ | | | | | | | | | | +-------v--+ +--------v---+ +-------v----+ +------v-----+ +------v------+ | UserSvc | |CatalogSvc | |OrderSvc | |PaymentSvc | |DeliverySvc | +-------+--+ +--------+---+ +-------+----+ +------+-----+ +------+------+ | | | | | +-------------+-------------+-------------+--------------+ | Kafka / Event Bus | +-------------------+---------------------+ | | | +---------v------+ +--------v------+ +---------v------+ |NotificationSvc | |InventorySvc | |AnalyticsSvc | +----------------+ +---------------+ +----------------+ | Redis Cache Cluster | +-------------------+----------------------+ | | | PostgreSQL Elasticsearch Object Storage 4. C4 Context Diagram +----------------+ | Customer | +-------+--------+ | | Food Ordering Platform | +------------------+--------------------+ | | | +-----v-----+ +------v------+ +------v------+ |Restaurant | |Payment | |Delivery | |Owner | |Gateway | |Driver | +-----------+ +-------------+ +-------------+ 5. C4 Container Diagram +-------------------+ | API Gateway | +---------+---------+ | +----------+----------+----------+----------+ | | | | | +----v---+ +----v---+ +----v---+ +----v---+ +----v----+ |UserSvc | |MenuSvc | |OrderSvc| |CartSvc | |Payment | +----+---+ +----+---+ +----+---+ +----+---+ +----+----+ | | | | | +----------+----------+----------+----------+ | Kafka | +----------------+----------------+ | | +------v------+ +--------v------+ |Notification | |DeliverySvc | +-------------+ +---------------+ 6. Entity DiagramUser ---- id name phone address Restaurant ------------ id name location status Menu ---- id restaurantId title MenuItem --------- id menuId name price Cart ---- id userId CartItem --------- id cartId menuItemId quantity Order ------ id userId restaurantId status totalPrice OrderItem --------- id orderId menuItemId quantity price Payment -------- id orderId status transactionId Driver ------- id name vehicle Delivery --------- id driverId orderId status RelationshipUser | |1 | |N Order Restaurant | |1 | |N Menu Menu | |1 | |N MenuItem Order | |1 | |N OrderItem Driver | |1 | |N Delivery 7. Sequence Diagram (Place Order)Customer | | Browse Menu | v Catalog Service | | Add Cart | v Cart Service | | Checkout | v Order Service | | Validate Menu | v Inventory Service | | Reserve Items | v Payment Service | | Charge Customer | v Payment Gateway | | Success | v Kafka | +------------------------------+ | | v v Restaurant Service Notification Service | | Accept Order | v Delivery Service | | Assign Driver | v Driver | | Deliver | v Customer 8. Database DesignDataStorageUserPostgreSQLRestaurantPostgreSQLMenuPostgreSQLOrdersPostgreSQLCartRedisSearchElasticsearchImagesObject Storage9. Kafka Topicsorder-created payment-success payment-failed restaurant-accepted restaurant-rejected driver-assigned driver-location delivery-started delivery-completed notification-event 10. Cache StrategyRedisRestaurant Cache Menu Cache Popular Foods Shopping Cart Session Rate Limiter Driver Location 11. Sharding StrategyShard = hash(userId) OrdersShard = hash(orderId) RestaurantsShard = City 12. Order State MachineCreated ↓ Payment Pending ↓ Paid ↓ Restaurant Accepted ↓ Preparing ↓ Driver Assigned ↓ Picked Up ↓ On The Way ↓ Delivered ↓ Completed Failure PathCreated ↓ Payment Failed ↓ Cancelled 13. ADR (Architecture Decision Records)ADR-001Decision: استفاده از Microservices.Reason: جداسازی دامنه‌های کسب‌وکار (کاربر، منو، سفارش، پرداخت و ارسال)، استقرار مستقل و مقیاس‌پذیری بهتر.ADR-002Decision: استفاده از PostgreSQL برای سفارش‌ها.Reason: سفارش و پرداخت نیازمند تراکنش‌های ACID و سازگاری قوی هستند.ADR-003Decision: استفاده از Redis برای سبد خرید.Reason: داده‌های Cart موقتی هستند و نیاز به دسترسی بسیار سریع دارند.ADR-004Decision: استفاده از Kafka برای رویدادها.Reason: جداسازی سرویس‌ها، پردازش غیرهمزمان و قابلیت Retry.ADR-005Decision: استفاده از Elasticsearch برای جستجو.Reason: جستجوی سریع بر اساس نام غذا، رستوران، دسته‌بندی و فیلترها.ADR-006Decision: ذخیره تصاویر در Object Storage.Reason: کاهش بار پایگاه داده، ادغام با CDN و مقیاس‌پذیری بالا.14. Failure ScenariosFailureSolutionPayment Gateway DownRetry + Circuit Breaker + Outbox PatternRestaurant OfflineCancel Order یا پیشنهاد رستوران جایگزینDriver CancelledReassign DriverKafka FailureReplication + Dead Letter QueueRedis FailureCache Rebuild + Fallback to DBDatabase FailureReplication + Automatic FailoverDuplicate OrderIdempotency KeyInventory Race ConditionOptimistic Lock یا Reservation Mechanism15. Trade-offsChoiceProsConsPostgreSQLACID، تراکنش قویمقیاس‌پذیری افقی دشوارترRedis Cartسرعت بسیار بالاداده‌ها موقتی هستندKafkaپردازش غیرهمزمان، مقیاس‌پذیریپیچیدگی عملیاتیElasticsearchجستجوی سریع و انعطاف‌پذیرنیاز به همگام‌سازی با دیتابیسMicroservicesتوسعه و استقرار مستقلپیچیدگی ارتباطات و مانیتورینگEvent-Drivenانعطاف‌پذیری و توسعه‌پذیریاشکال‌زدایی و ردیابی رویدادها دشوارتراین سند، اجزای کلیدی مورد انتظار در یک مصاحبه طراحی سیستم را پوشش می‌دهد: نیازمندی‌ها، معماری سطح بالا، نمودارهای C4، ERD، Sequence Diagram، طراحی پایگاه داده، استراتژی کش، شاردینگ، ماشین حالت سفارش، ADRها، سناریوهای خطا و تحلیل Trade-offها.

chat

Akhtar Sabzi — Mon, 20 Jul 2026 23:20:15 +0330

wallet

Akhtar Sabzi — Mon, 20 Jul 2026 23:10:19 +0330

99.99%ConsistencyStrong ConsistencyLatency<200 msScalabilityHorizontalSecurityPCI DSS Encryption AuditHigh Level Architecture Client | API Gateway | Authentication Service | +------------------+----------------+ | | Wallet Service Transaction Service | | +------------+----------------------+ | Ledger Service | Kafka Event Bus | +--------------+------------------+ | | Notification Audit Service | Email / SMS / Push | PostgreSQL Cluster | Redis Clusterچرا Ledger Service جداست؟در سیستم بانکیWallet فقط موجودی نیست.اصل حقیقت (Source of Truth)همیشه Ledger است.مثلاًWallet A100$↓Transfer 30$↓Wallet BLedgerDebit Wallet A Credit Wallet Bاگر Wallet خراب شودLedger هنوز حقیقت را نگه داشته است.Entity Diagram+-----------+ | User | +-----------+ | userId PK | | name | | kycStatus | +-----------+ 1 | * +------------+ | Wallet | +------------+ | walletId | | userId FK | | currency | | status | +------------+ 1 | * +----------------+ | LedgerAccount | +----------------+ | accountId | | walletId | | balance | +----------------+ 1 | * +----------------+ | Transaction | +----------------+ | transactionId | | type | | amount | | status | | createdAt | +----------------+ 1 | * +----------------+ | LedgerEntry | +----------------+ | entryId | | debitAccount | | creditAccount | | amount | +----------------+ مهم‌ترین نکته طراحیهیچوقت Balance را مستقیماً Update نکن.اشتباهUPDATE wallet SET balance=balance-100در سیستم بانکی این کار ممنوع است.در عوضLedger Entry Debit CreditبعداًBalanceاز روی Ledger محاسبه می‌شود.Double Entry Accountingفرض کنیدWallet A100$Wallet B50$Transfer30$LedgerWallet A -30 Wallet B +30جمع کل-30 +30 = 0هیچ پولی خلق نشد.Sequence DiagramTransfer MoneyClient | Wallet Service | Validate Wallet | Transaction Service | Check Balance | Ledger Service | Create Debit Entry | Create Credit Entry | Commit | Publish Kafka | Notification | Return SuccessجزئیاتClient | API Gateway | Wallet Service | Ledger Service | PostgreSQL | Kafka | Notification | ClientC4 ModelLevel 1Customer | | Digital Wallet PlatformLevel 2API Gateway Authentication Wallet Service Ledger Service Transaction Service Notification Service Audit Service Fraud Detection KYC ServiceLevel 3داخل Wallet ServiceWallet API Wallet Validation Limit Checker Balance Calculator Ledger Adapter Transaction Coordinator Event PublisherADRADR-001PostgreSQL به جای MongoDecisionPostgreSQLReasonACID Transaction ConsistencyADR-002Double Entry AccountingDecisionLedgerReasonAudit Financial Safety RecoveryADR-003KafkaDecisionKafkaReasonAsync Notification Audit Analytics RetryADR-004RedisDecisionRedis CacheReasonBalance Cache Rate Limit SessionADR-005Idempotency Keyتمام درخواست‌های انتقال باید دارای شناسه یکتای Idempotency-Key باشند تا در صورت Retry یا دوبار کلیک کاربر، تراکنش تکراری ایجاد نشود.ADR-006Saga Patternبرای انتقال بین سرویس‌های مختلف از Saga استفاده می‌شود تا در صورت شکست بخشی از فرآیند، عملیات جبرانی (Compensation) انجام شود.DatabaseDataDatabaseUserPostgreSQLWalletPostgreSQLLedgerPostgreSQLTransactionPostgreSQLCacheRedisEventsKafkaSearchElasticsearchSequence برای TransferClient ↓ Gateway ↓ Wallet Service ↓ Transaction Service ↓ Ledger ↓ Commit ↓ Kafka ↓ NotificationFailure ScenariosNotification DownTransfer موفق است. Kafka بعداً Notification را ارسال می‌کند.Wallet Service CrashTransaction RollbackKafka Downاز Outbox Pattern استفاده می‌شود؛ ابتدا تراکنش و رویداد در یک تراکنش دیتابیس ثبت می‌شوند و سپس یک Outbox Publisher رویداد را به Kafka ارسال می‌کند. بنابراین هیچ رویدادی از دست نمی‌رود.Database CrashReplication Automatic FailoverDuplicate RequestIdempotency KeyConcurrent WithdrawSELECT ... FOR UPDATEیاOptimistic LockامنیتTLS برای تمام ارتباطاتEncryption at RestHSM برای نگهداری کلیدهاJWT + OAuth2RBACAudit Log غیرقابل تغییر (Immutable)Tokenization برای اطلاعات حساسKYC/AML و موتور تشخیص FraudBottleneckهاBottleneckSolutionLedger WritePartition بر اساس WalletId + Connection PoolBalance ReadRedis Cache با Invalidating پس از CommitNotificationKafka + Consumer GroupAuditAsync ConsumerReportingRead ReplicaHot WalletSharding بر اساس WalletId