You may view those salaries as appropriate for leading companies of this size or immoral and outrageous. But either way executive comp is not the big problem with US healthcare costs.

  SELECT
  * 
  FROM jobs 
  WHERE partition_key = (
    SELECT partition_key 
    FROM jobs 
    ORDER BY partition_key 
    LIMIT 1
    SKIP LOCKED
  )
  ORDER BY submitted_at
  FOR UPDATE SKIP LOCKED;

- 1 Terraform workspace per environment (dev, test, prod, etc.).

- Managing changes to workspaces / environments is done with whatever approach you use for everything else (releasing master using some kind of CICD pipeline or release branches). The Terraform is preferably in the same git repositories as your code but can be separate.

- The CICD tool injects an environment variable into the build to select the appropriate workspace and somehow supplies credentials granting access to a role that can be assumed in the appropriate account.

- A region module / folder that defines the resources you want in each region. This is your "main" module that specifies everything you want.

- Minimal top level terraform that instantiates multiple AWS providers (one for each region) and uses them to create region modules. Any cross region or global resources are also defined here.

- The region module uses submodules to create the actual resources (RDS, VPCs, etc.) as needed.

This approach assumes you want to deploy to all your regions in one go. That may not be the case.

Between Dynamodb, Cassandra, and Scylla seems like that problem set is somewhat a solved problem? I know those products continue to move forward, but they all work really well at this point and solve the fundamental problem to a good degree.

Because you've introduced static hash keys ("user", "email", etc) you've had to manually partition which DDB should do for you automatically. And while you covered the partition size limit you're also likely to have write performance issues because you're not distributing writes to the "user" and "email" hash keys.

Single-table design should distribute writes and minimize roundtrips to the database. user#12345 as a hash key and range keys of 'User', 'Email#jo@email.com', 'Email#joe@email.com', etc achieve those goals. If you need to query and/or sort on a large number of attributes it's going to be easier, faster, and probably cheaper to stream data into Elasticsearch or similar to support those queries.

Also you can game the COBRA enrollment window. You have 60 days from your loss of coverage to elect COBRA and once you elect COBRA you have another 45 days to submit payment. You can elect on the 59th/60th day and then pay 45 days later if you ended up needing the coverage. If you don't need the coverage don't pay.

https://docs.aws.amazon.com/service-authorization/latest/ref...

The condition keys specifically are here and you can see keys to control access to storage class, tagging, etc.

https://docs.aws.amazon.com/service-authorization/latest/ref...

If you want type safe SQL in particular, you can pry JOOQ out of my cold dead hands.

That's different from how Raven has just wildly mistated their capabilities.

If you're not interested in a science experiment, Cassandra (or Scylla) are the multi-master databases that are mainstream and proven to work and scale. They're not fun or sexy and their feature set is much smaller but they do what they say and they work. Or AWS/GCP/Azure will happily give you an API for one.

If a particular application has 10 patterns that support all the applications UI interactions, then a simple, constrained solution like htmx that supports those 10 patterns is preferable (to me) than an unconstrained solution like Typescript + React where each developer will likely use their creativity and experience to design slightly or wildly bespoke solutions for each feature.

They do actually provide quite a lot of detail about Aurora storage this works. This 2019 reinvent talk gets pretty deep into the weeds.

https://www.youtube.com/watch?v=uaQEGLKtw54

https://d1.awsstatic.com/events/reinvent/2019/REPEAT_Amazon_...