rponte

package br.com.zup.edu

import io.grpc.health.v1.HealthCheckRequest
import io.grpc.health.v1.HealthCheckResponse
import io.grpc.health.v1.HealthGrpc
import io.grpc.stub.StreamObserver
import javax.inject.Singleton

@Singleton
class HealthCheckerService: HealthGrpc.HealthImplBase() {

rponte

package br.com.zup.edu.bugfix;

import io.micronaut.context.annotation.Replaces;
import io.micronaut.core.async.publisher.AsyncSingleResultPublisher;
import io.micronaut.grpc.server.GrpcEmbeddedServer;
import io.micronaut.grpc.server.health.GrpcServerHealthIndicator;
import io.micronaut.health.HealthStatus;
import io.micronaut.management.health.indicator.HealthResult;
import org.reactivestreams.Publisher;

rponte

Pretende usar UUID como PK em vez de Int/BigInt no seu banco de dados? Pense novamente...

TL;TD

Não use UUID como PK nas tabelas do seu banco de dados.

Um pouco mais de detalhes

rponte

sudo hwclock -s

rponte

-- first, install the pgcrypto module
CREATE EXTENSION pgcrypto;

-- this is how to use its crypto-functions and encoding the value into base64 (by default postgresql uses bytea)
with sensitive_info (email, encrypted_email) as (
	values ('[email protected]', 'ww0EBwMC1V/tU6ZYV3Nq0kEBz8iqdRYE0A/zL3dQ+du9Ex+GkSDzz3Llq8g1yCoa9XpNbhKzK7U5
b1EtUYzUMer8XSaCwdFSPKmbSfJo1btoSQ==')
)
select encode(pgp_sym_encrypt(s.email, 'mySecretKey'), 'base64')           as encrypted_data
      ,pgp_sym_decrypt(decode(s.encrypted_email, 'base64'), 'mySecretKey') as decrypted_data

rponte

import java.util.LinkedHashMap;
import java.util.Map;

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

/**
 * Class responsible for parsing an encoded-text in TLV (Tag-Length-Value) format
 */
public class TLVParser {

rponte

# Use postgres/example user/password credentials
version: '3.1'

services:
  db:
    image: "postgres:10.6"
    restart: always
    ports:
      - 5432:5432
    environment:

rponte

-- Create the database user
CREATE USER rponte WITH PASSWORD '123';

-- Create the database
CREATE DATABASE mydb WITH  OWNER      = rponte 
                           ENCODING   = 'UTF8' 
                           LC_CTYPE   = 'en_US.UTF-8' 
                           LC_COLLATE = 'en_US.UTF-8'
                           TEMPLATE   = template0;

rponte

@tef_ebooks articles

• Write code that is easy to delete, not easy to extend
• Write code that’s easy to delete, and easy to debug too
• Repeat yourself, do more than one thing, and rewrite everything
• How do you cut a monolith in half?
• Scaling in the presence of errors—don’t ignore them

twitter: @tef_ebooks

rponte

Turning PostgreSQL into a queue serving 10,000 jobs per second

RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.

On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.

So, many developers have started going straight t