Upgrade to Pro — share decks privately, control downloads, hide ads and more …

High availability by offloading work - background jobs, message queues, or Kafka

High availability by offloading work - background jobs, message queues, or Kafka

Talk at RubyConf Colombia 2019

Kerstin Puschke

September 20, 2019
Tweet

More Decks by Kerstin Puschke

Other Decks in Technology

Transcript

  1. @titanoboa42 community of
 users
 can interact meaningfully
 with the system

    whenever needed High Availability community of
 users
 can interact meaningfully
 with the system whenever needed
  2. @titanoboa42 • No breaking changes to job parameters • Changes

    need to be backwards compatible until legacy jobs have been processed Job queued and processed by different versions
  3. @titanoboa42 • “At least” vs. “at most” once delivery •

    Idempotent jobs & at least once delivery No exactly once delivery
  4. @titanoboa42 • Don’t queue from within a db transaction •

    Job runs before commit, or in case of rollback Non-transactional queuing
  5. @titanoboa42 • Don’t queue from within a db transaction •

    Job runs before commit, or in case of rollback • Commit first: Job not guaranteed to be queued Non-transactional queuing
  6. @titanoboa42 • SAGA events/choreography: jobs queue jobs • easy to

    build, hard to maintain or debug Out of order delivery
  7. @titanoboa42 • SAGA events/choreography: jobs queue jobs • easy to

    build, hard to maintain or debug • SAGA command/orchestrator Out of order delivery
  8. @titanoboa42 • Aborted and requeued • Job may not finish

    before being aborted again Long running jobs - Sidekiq
  9. @titanoboa42 • Split job into collection and task to be

    done • Checkpoint after iteration & requeue Large collections
  10. @titanoboa42 • Shutdown workers anytime • Disaster prevention • Data

    integrity Interruptible job with automatic resuming
  11. @titanoboa42 • Based on task queues • Complex overall system,

    simple concrete jobs • Great for monolith Background jobs
  12. @titanoboa42 Topic with queues
 provides
 advanced routing App Server Business


    Partners Support
 Contracts Orders Messaging Middleware
  13. @titanoboa42 Topic with queues
 provides
 advanced routing App Server Message

    Queue Business
 Partners Support
 Contracts Orders Message Queue Messaging Middleware
  14. @titanoboa42 • Avoid n:m routing • Better representation of domain:


    multiple messages routed 1:n, n:1 instead Keep breaking changes manageable
  15. @titanoboa42 • No exactly once delivery • No strong consistency

    • Out of order delivery Lack of guarantees
  16. @titanoboa42 • Based on queues and topics • Complex overall

    system • Simple message consumers Message oriented middleware
  17. @titanoboa42 • Events persisted into append-only log • Consumers read

    shared log • Stateless broker (no queues) Event log
  18. @titanoboa42 • Single source of truth (e.g. for event sourcing)

    • High throughput applications Event logs
  19. @titanoboa42 • Shared log, no queues • For event sourcing

    & high throughput applications Event logs